Tom,

Re: SwapAxis - I find modal things a PITA, mostly because I WILL forget about them. I use G52/G92, but sometimes have to interrupt a program in process, and if I forget to clear the offsets, it WILL bite me in the a$$ at some point. So I am hesitant to add another, if I can avoid it. I make quite enough mistakes on my own, without making things even more complicated for myself! :-)

Re: offsets - I must not be following your example properly, because it doesn't add up for me. In your example, I believe the second case, applying the 2" offset, is incorrect. First, I'm no expert on G-code, but I believe it would be customary to do a G49 to remove the offset for the current tool, do the tool change, THEN apply the offset for the new tool. This is certainly how it is always done in my G-code, because I generate it that way, and I am willing to live with that limitation, as I kind of have to remove the offset to give me enough room to do the toolchange.

Here's how I currently do it: My knee is currently setup so A+ is up, A- is down, and the A axis fixture 0 is the knee position corresponding to my longest tool. Machine position can really be anything at all, and the fixture offset shifts it to wherever I want my work zero to be for that job. In your example, in the case of a 1" offset, when no offset is currently applied (so the knee is at 0.000), I would propose simply adding 1" to currentA, which would result in the knee being moved upward 1" (where/how the actual move occurs is not clear to me yet....). Now if I switch to a tool with a 2" offset, I would change currentZ to 1" - 1" + 2", or +2", though I would always first remove the existing offset, returning the knee to 0.000). The existing code appears also to do exactly that - it adds back settings->tool_length_offset, then subtract on settings->tool_table[index].length.

You are correct about settings->tool_length_offset being used in a number of places, though they all seem to be pretty straight-forward, and appear easily duplicated in the A axis code. Certainly worth a try - little to lose anyway. OTOH, if you want to make the changes to add offsets for X, Y, Z, and A, I'll be your first tester! :-) Certainly if I make the change for A, and it works, I'll send you the modified code.

Python for a scripting language would be fine - not my first choice (I really hate languages for which white-space is significant....), but Python is very popular, and quite usable. Tcl could be another choice. Personally, I like Perl, but I've been using it for over 20 years. Not a fan of VB at ALL!

For your last question - as I alluded to earlier, I set the knee zero, using fixture offsets, so the A=0.000 is the knee position corresponding to the tip of my longest tool (which is 8") touching the top of my workpiece, with the quill (Z axis) at 0.000. I do this by setting the quill to where I want my fixture 0 to be (usually, but not always, 2" below the Z home position at the Z+ limit), touching-off using probing and raising the knee, then zeroing the A DRO. One thing about tool changes and tool length settings - Near as I can tell, there are a number of different ways to do it, and no clear "best" or even most common method. When I setup my macros, everyone I talked to seemed to have what they thought was the only "right" way to do it. I chose the method I use based on safety and idiot-proof-ness (this is important, as I AM an idiot!). Defining A=0 as the position corresponding to the longest tool ensures that removing the offset will always drive the knee in a "safe" direction (down). It's worked well for me.

I must be crazy.... I'm kinda looking forward to digging into this....

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
>  
> Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
>  
> Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
>  
> MachineZ = CurrentZ + tool_length_offset
>  
> So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
>  
> 11 = 10 + 1
>  
> Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
>  
> 11 = 9 + 2
>   
> If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
>  
> Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
>  
> Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
>  
> This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
>  
> You bring up lots of good points to stimulate discussion Ray.
>  
> Thanks
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, November 6, 2011 4:17 PM
> Subject: [DynoMotion] Re: Customizing Tool Changes
>
>
>  
> Tom,
>
> I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
>
> Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
>
> I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
>
> I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> >  
> > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> >  
> > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> >  
> > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> >  
> > Regards
> > TK
> >  
> >  
> >  
> >  
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Saturday, November 5, 2011 8:38 PM
> > Subject: [DynoMotion] Customizing Tool Changes
> >
> >
> >  
> > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> >
> > A toolchange therefore requires several steps:
> >
> > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > 2) Prompt the user to load the new tool
> > 3) Execute an M6 Tn for the new tool
> > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> >
> > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> >
> > #3 is a no-brainer, just G-code.
> >
> > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> >
> > Do I have this right?
> >
> > Regards,
> > Ray L.
> >
>

Very interesting topic indeed.

This is just a brain-dump, so take it with a grain....


I once had an old Kondia knee mill I planned to retrofit to CNC. My plan was to use the quill for the primary Z and index the knee as needed to shift around the Z's envelope of motion. If this is all you need then perhaps you could use the Interpreter's User Callback to call for an index and simply update your current fixture offset(G54/55/56/etc...).

In this manner you can leave your tool comps accurate.



Other than that I cannot see a need to interpolate both z's. I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part.

Just because I cannot see a practical need does not mean that one does not exist, so please share a reason if you have one.


As Tom stated, I would be using IronPython scripts in my Usercallback handler(because I am using the c# gcode interface in Machine Manager).

In a script you have complete and dynamic access to all Dynomotion and application objects. This makes custom integrations like what you are after a breeze(without the need for modifying source, etc...).

Good luck with solving your challenge.

My 2c,

Brad Murry

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
>  
> Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
>  
> Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
>  
> MachineZ = CurrentZ + tool_length_offset
>  
> So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
>  
> 11 = 10 + 1
>  
> Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
>  
> 11 = 9 + 2
>   
> If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
>  
> Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
>  
> Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
>  
> This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
>  
> You bring up lots of good points to stimulate discussion Ray.
>  
> Thanks
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, November 6, 2011 4:17 PM
> Subject: [DynoMotion] Re: Customizing Tool Changes
>
>
>  
> Tom,
>
> I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
>
> Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
>
> I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
>
> I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> >  
> > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> >  
> > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> >  
> > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> >  
> > Regards
> > TK
> >  
> >  
> >  
> >  
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Saturday, November 5, 2011 8:38 PM
> > Subject: [DynoMotion] Customizing Tool Changes
> >
> >
> >  
> > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> >
> > A toolchange therefore requires several steps:
> >
> > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > 2) Prompt the user to load the new tool
> > 3) Execute an M6 Tn for the new tool
> > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> >
> > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> >
> > #3 is a no-brainer, just G-code.
> >
> > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> >
> > Do I have this right?
> >
> > Regards,
> > Ray L.
> >
>

I do agree with the python. I mean I like it and it is fairly human readable which means I can ask technicians to make tweeks when I do not have time. But no matter how long I use it it boild my blood when I get an "Unexpected Indent Error...." Grr....

The only reason I use it is because the IronPython implementation is extremely performant and can access my .net objects with no fuss thanks to the DLR.

There is an IronJS project in alpha and as soon as it is more stable and mature I'll add support for it so everyting is back between nice and tidy curly braces.

-Brad Murry

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> Re: SwapAxis - I find modal things a PITA, mostly because I WILL forget about them. I use G52/G92, but sometimes have to interrupt a program in process, and if I forget to clear the offsets, it WILL bite me in the a$$ at some point. So I am hesitant to add another, if I can avoid it. I make quite enough mistakes on my own, without making things even more complicated for myself! :-)
>
> Re: offsets - I must not be following your example properly, because it doesn't add up for me. In your example, I believe the second case, applying the 2" offset, is incorrect. First, I'm no expert on G-code, but I believe it would be customary to do a G49 to remove the offset for the current tool, do the tool change, THEN apply the offset for the new tool. This is certainly how it is always done in my G-code, because I generate it that way, and I am willing to live with that limitation, as I kind of have to remove the offset to give me enough room to do the toolchange.
>
> Here's how I currently do it: My knee is currently setup so A+ is up, A- is down, and the A axis fixture 0 is the knee position corresponding to my longest tool. Machine position can really be anything at all, and the fixture offset shifts it to wherever I want my work zero to be for that job. In your example, in the case of a 1" offset, when no offset is currently applied (so the knee is at 0.000), I would propose simply adding 1" to currentA, which would result in the knee being moved upward 1" (where/how the actual move occurs is not clear to me yet....). Now if I switch to a tool with a 2" offset, I would change currentZ to 1" - 1" + 2", or +2", though I would always first remove the existing offset, returning the knee to 0.000). The existing code appears also to do exactly that - it adds back settings->tool_length_offset, then subtract on settings->tool_table[index].length.
>
> You are correct about settings->tool_length_offset being used in a number of places, though they all seem to be pretty straight-forward, and appear easily duplicated in the A axis code. Certainly worth a try - little to lose anyway. OTOH, if you want to make the changes to add offsets for X, Y, Z, and A, I'll be your first tester! :-) Certainly if I make the change for A, and it works, I'll send you the modified code.
>
> Python for a scripting language would be fine - not my first choice (I really hate languages for which white-space is significant....), but Python is very popular, and quite usable. Tcl could be another choice. Personally, I like Perl, but I've been using it for over 20 years. Not a fan of VB at ALL!
>
> For your last question - as I alluded to earlier, I set the knee zero, using fixture offsets, so the A=0.000 is the knee position corresponding to the tip of my longest tool (which is 8") touching the top of my workpiece, with the quill (Z axis) at 0.000. I do this by setting the quill to where I want my fixture 0 to be (usually, but not always, 2" below the Z home position at the Z+ limit), touching-off using probing and raising the knee, then zeroing the A DRO. One thing about tool changes and tool length settings - Near as I can tell, there are a number of different ways to do it, and no clear "best" or even most common method. When I setup my macros, everyone I talked to seemed to have what they thought was the only "right" way to do it. I chose the method I use based on safety and idiot-proof-ness (this is important, as I AM an idiot!). Defining A=0 as the position corresponding to the longest tool ensures that removing the offset will always drive the knee in a "safe" direction (down). It's worked well for me.
>
> I must be crazy.... I'm kinda looking forward to digging into this....
>
> Regards,
> Ray L.
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
> >  
> > Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
> >  
> > Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
> >  
> > MachineZ = CurrentZ + tool_length_offset
> >  
> > So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
> >  
> > 11 = 10 + 1
> >  
> > Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
> >  
> > 11 = 9 + 2
> >   
> > If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
> >  
> > Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
> >  
> > Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
> >  
> > This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
> >  
> > You bring up lots of good points to stimulate discussion Ray.
> >  
> > Thanks
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, November 6, 2011 4:17 PM
> > Subject: [DynoMotion] Re: Customizing Tool Changes
> >
> >
> >  
> > Tom,
> >
> > I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
> >
> > Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
> >
> > I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
> >
> > I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> > >  
> > > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> > >  
> > > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> > >  
> > > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> > >  
> > > Regards
> > > TK
> > >  
> > >  
> > >  
> > >  
> > >
> > >
> > > ________________________________
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, November 5, 2011 8:38 PM
> > > Subject: [DynoMotion] Customizing Tool Changes
> > >
> > >
> > >  
> > > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> > >
> > > A toolchange therefore requires several steps:
> > >
> > > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > > 2) Prompt the user to load the new tool
> > > 3) Execute an M6 Tn for the new tool
> > > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> > >
> > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> > >
> > > #3 is a no-brainer, just G-code.
> > >
> > > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> > >
> > > Do I have this right?
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>

Brad,

"I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part." - Not sure I understand that statement. My quill has a bit under 5" of travel, the knee has almost 20". The quill travel is adequate for any one tool, but on a given job, I will use tools that vary in length from 1" (small endmills), to almost 8" (long drill bits), so I MUST use the knee.

I absolutely intend to look at what you're doing with C#, as that is my language of choice (at present.... :-)). In fact, I'm hoping to do my own UI for KMotionCNC in C# at some point. I'm glad to hear you will give scripting access to the internals. If that really would provide a way to do what I need without modifying Toms source code, that would be a nice way to go.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Very interesting topic indeed.
>
> This is just a brain-dump, so take it with a grain....
>
>
> I once had an old Kondia knee mill I planned to retrofit to CNC. My plan was to use the quill for the primary Z and index the knee as needed to shift around the Z's envelope of motion. If this is all you need then perhaps you could use the Interpreter's User Callback to call for an index and simply update your current fixture offset(G54/55/56/etc...).
>
> In this manner you can leave your tool comps accurate.
>
>
>
> Other than that I cannot see a need to interpolate both z's. I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part.
>
> Just because I cannot see a practical need does not mean that one does not exist, so please share a reason if you have one.
>
>
> As Tom stated, I would be using IronPython scripts in my Usercallback handler(because I am using the c# gcode interface in Machine Manager).
>
> In a script you have complete and dynamic access to all Dynomotion and application objects. This makes custom integrations like what you are after a breeze(without the need for modifying source, etc...).
>
> Good luck with solving your challenge.
>
> My 2c,
>
> Brad Murry
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
> >  
> > Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
> >  
> > Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
> >  
> > MachineZ = CurrentZ + tool_length_offset
> >  
> > So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
> >  
> > 11 = 10 + 1
> >  
> > Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
> >  
> > 11 = 9 + 2
> >   
> > If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
> >  
> > Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
> >  
> > Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
> >  
> > This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
> >  
> > You bring up lots of good points to stimulate discussion Ray.
> >  
> > Thanks
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, November 6, 2011 4:17 PM
> > Subject: [DynoMotion] Re: Customizing Tool Changes
> >
> >
> >  
> > Tom,
> >
> > I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
> >
> > Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
> >
> > I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
> >
> > I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> > >  
> > > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> > >  
> > > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> > >  
> > > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> > >  
> > > Regards
> > > TK
> > >  
> > >  
> > >  
> > >  
> > >
> > >
> > > ________________________________
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, November 5, 2011 8:38 PM
> > > Subject: [DynoMotion] Customizing Tool Changes
> > >
> > >
> > >  
> > > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> > >
> > > A toolchange therefore requires several steps:
> > >
> > > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > > 2) Prompt the user to load the new tool
> > > 3) Execute an M6 Tn for the new tool
> > > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> > >
> > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> > >
> > > #3 is a no-brainer, just G-code.
> > >
> > > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> > >
> > > Do I have this right?
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>

Brad,

Oooooh! Spaces BAD! Curly braces GOOD!! :-)

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> I do agree with the python. I mean I like it and it is fairly human readable which means I can ask technicians to make tweeks when I do not have time. But no matter how long I use it it boild my blood when I get an "Unexpected Indent Error...." Grr....
>
> The only reason I use it is because the IronPython implementation is extremely performant and can access my .net objects with no fuss thanks to the DLR.
>
> There is an IronJS project in alpha and as soon as it is more stable and mature I'll add support for it so everyting is back between nice and tidy curly braces.
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Tom,
> >
> > Re: SwapAxis - I find modal things a PITA, mostly because I WILL forget about them. I use G52/G92, but sometimes have to interrupt a program in process, and if I forget to clear the offsets, it WILL bite me in the a$$ at some point. So I am hesitant to add another, if I can avoid it. I make quite enough mistakes on my own, without making things even more complicated for myself! :-)
> >
> > Re: offsets - I must not be following your example properly, because it doesn't add up for me. In your example, I believe the second case, applying the 2" offset, is incorrect. First, I'm no expert on G-code, but I believe it would be customary to do a G49 to remove the offset for the current tool, do the tool change, THEN apply the offset for the new tool. This is certainly how it is always done in my G-code, because I generate it that way, and I am willing to live with that limitation, as I kind of have to remove the offset to give me enough room to do the toolchange.
> >
> > Here's how I currently do it: My knee is currently setup so A+ is up, A- is down, and the A axis fixture 0 is the knee position corresponding to my longest tool. Machine position can really be anything at all, and the fixture offset shifts it to wherever I want my work zero to be for that job. In your example, in the case of a 1" offset, when no offset is currently applied (so the knee is at 0.000), I would propose simply adding 1" to currentA, which would result in the knee being moved upward 1" (where/how the actual move occurs is not clear to me yet....). Now if I switch to a tool with a 2" offset, I would change currentZ to 1" - 1" + 2", or +2", though I would always first remove the existing offset, returning the knee to 0.000). The existing code appears also to do exactly that - it adds back settings->tool_length_offset, then subtract on settings->tool_table[index].length.
> >
> > You are correct about settings->tool_length_offset being used in a number of places, though they all seem to be pretty straight-forward, and appear easily duplicated in the A axis code. Certainly worth a try - little to lose anyway. OTOH, if you want to make the changes to add offsets for X, Y, Z, and A, I'll be your first tester! :-) Certainly if I make the change for A, and it works, I'll send you the modified code.
> >
> > Python for a scripting language would be fine - not my first choice (I really hate languages for which white-space is significant....), but Python is very popular, and quite usable. Tcl could be another choice. Personally, I like Perl, but I've been using it for over 20 years. Not a fan of VB at ALL!
> >
> > For your last question - as I alluded to earlier, I set the knee zero, using fixture offsets, so the A=0.000 is the knee position corresponding to the tip of my longest tool (which is 8") touching the top of my workpiece, with the quill (Z axis) at 0.000. I do this by setting the quill to where I want my fixture 0 to be (usually, but not always, 2" below the Z home position at the Z+ limit), touching-off using probing and raising the knee, then zeroing the A DRO. One thing about tool changes and tool length settings - Near as I can tell, there are a number of different ways to do it, and no clear "best" or even most common method. When I setup my macros, everyone I talked to seemed to have what they thought was the only "right" way to do it. I chose the method I use based on safety and idiot-proof-ness (this is important, as I AM an idiot!). Defining A=0 as the position corresponding to the longest tool ensures that removing the offset will always drive the knee in a "safe" direction (down). It's worked well for me.
> >
> > I must be crazy.... I'm kinda looking forward to digging into this....
> >
> > Regards,
> > Ray L.
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
> > >  
> > > Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
> > >  
> > > Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
> > >  
> > > MachineZ = CurrentZ + tool_length_offset
> > >  
> > > So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
> > >  
> > > 11 = 10 + 1
> > >  
> > > Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
> > >  
> > > 11 = 9 + 2
> > >   
> > > If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
> > >  
> > > Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
> > >  
> > > Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
> > >  
> > > This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
> > >  
> > > You bring up lots of good points to stimulate discussion Ray.
> > >  
> > > Thanks
> > > TK
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, November 6, 2011 4:17 PM
> > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
> > >
> > > Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
> > >
> > > I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
> > >
> > > I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> > > >  
> > > > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> > > >  
> > > > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> > > >  
> > > > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >  
> > > >  
> > > >  
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > Subject: [DynoMotion] Customizing Tool Changes
> > > >
> > > >
> > > >  
> > > > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> > > >
> > > > A toolchange therefore requires several steps:
> > > >
> > > > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > > > 2) Prompt the user to load the new tool
> > > > 3) Execute an M6 Tn for the new tool
> > > > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> > > >
> > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> > > >
> > > > #3 is a no-brainer, just G-code.
> > > >
> > > > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> > > >
> > > > Do I have this right?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

Hello Ray,

Well yours must be bigger than mine was... My quill was in the neighborhood of 6" and although my knee's ways were around 20" the knee/saddle casting was huge resulting in maybe 7-8" of useful travel.

Still, what do you think about just indexing the knee to different "work offsets"? This would not involve any 'axis swapping', just command a single axis move from the user callback and update whatever work offset you are currently using(G54/55/56/etc...)

With this approach you would only ever be interpreting g code using the quill. You could probably implement this behavior right now as -is by using custom M codes to handle positioning the knee to preset levels in conjunction with setting up 3-4 work offsets to match these presets.

As an example:

G54 = X0.0 Y0.0 Z0.0
G55 = X0.0 Y0.0 Z-4.0
G56 = X0.0 Y0.0 Z-8.0
G57 = X0.0 Y0.0 Z-12.0

Or something to that effect-I'm certain you get the idea.


Looking forward to working with other devs on the c#. There is already a rich framework for GUI in Machine Manager that allows for complete customization without adding a bunch of GUI to machine code plumbing.

-Brad Murry

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> "I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part." - Not sure I understand that statement. My quill has a bit under 5" of travel, the knee has almost 20". The quill travel is adequate for any one tool, but on a given job, I will use tools that vary in length from 1" (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
>
> I absolutely intend to look at what you're doing with C#, as that is my language of choice (at present.... :-)). In fact, I'm hoping to do my own UI for KMotionCNC in C# at some point. I'm glad to hear you will give scripting access to the internals. If that really would provide a way to do what I need without modifying Toms source code, that would be a nice way to go.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Very interesting topic indeed.
> >
> > This is just a brain-dump, so take it with a grain....
> >
> >
> > I once had an old Kondia knee mill I planned to retrofit to CNC. My plan was to use the quill for the primary Z and index the knee as needed to shift around the Z's envelope of motion. If this is all you need then perhaps you could use the Interpreter's User Callback to call for an index and simply update your current fixture offset(G54/55/56/etc...).
> >
> > In this manner you can leave your tool comps accurate.
> >
> >
> >
> > Other than that I cannot see a need to interpolate both z's. I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part.
> >
> > Just because I cannot see a practical need does not mean that one does not exist, so please share a reason if you have one.
> >
> >
> > As Tom stated, I would be using IronPython scripts in my Usercallback handler(because I am using the c# gcode interface in Machine Manager).
> >
> > In a script you have complete and dynamic access to all Dynomotion and application objects. This makes custom integrations like what you are after a breeze(without the need for modifying source, etc...).
> >
> > Good luck with solving your challenge.
> >
> > My 2c,
> >
> > Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
> > >  
> > > Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
> > >  
> > > Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
> > >  
> > > MachineZ = CurrentZ + tool_length_offset
> > >  
> > > So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
> > >  
> > > 11 = 10 + 1
> > >  
> > > Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
> > >  
> > > 11 = 9 + 2
> > >   
> > > If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
> > >  
> > > Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
> > >  
> > > Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
> > >  
> > > This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
> > >  
> > > You bring up lots of good points to stimulate discussion Ray.
> > >  
> > > Thanks
> > > TK
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, November 6, 2011 4:17 PM
> > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
> > >
> > > Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
> > >
> > > I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
> > >
> > > I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> > > >  
> > > > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> > > >  
> > > > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> > > >  
> > > > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >  
> > > >  
> > > >  
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > Subject: [DynoMotion] Customizing Tool Changes
> > > >
> > > >
> > > >  
> > > > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> > > >
> > > > A toolchange therefore requires several steps:
> > > >
> > > > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > > > 2) Prompt the user to load the new tool
> > > > 3) Execute an M6 Tn for the new tool
> > > > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> > > >
> > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> > > >
> > > > #3 is a no-brainer, just G-code.
> > > >
> > > > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> > > >
> > > > Do I have this right?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

Brad,

I considered that approach a long time ago, but ruled it out pretty quickly. I think managing a slew of offsets like that would be a real PITA, and would REALLY complicate G-code generation, having to figure out which fixture to use when. I don't have any single jobs that need more than about 4-1/2" of travel, but I do have several that use pretty much all the quill travel between clearance height and drilling deep holes. I think you'd pretty much have to apply a different offset per tool, but I don't know the tool lengths when I generate the G-code. And, break a tool, and you've broken your code too.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello Ray,
>
> Well yours must be bigger than mine was... My quill was in the neighborhood of 6" and although my knee's ways were around 20" the knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
>
> Still, what do you think about just indexing the knee to different "work offsets"? This would not involve any 'axis swapping', just command a single axis move from the user callback and update whatever work offset you are currently using(G54/55/56/etc...)
>
> With this approach you would only ever be interpreting g code using the quill. You could probably implement this behavior right now as -is by using custom M codes to handle positioning the knee to preset levels in conjunction with setting up 3-4 work offsets to match these presets.
>
> As an example:
>
> G54 = X0.0 Y0.0 Z0.0
> G55 = X0.0 Y0.0 Z-4.0
> G56 = X0.0 Y0.0 Z-8.0
> G57 = X0.0 Y0.0 Z-12.0
>
> Or something to that effect-I'm certain you get the idea.
>
>
> Looking forward to working with other devs on the c#. There is already a rich framework for GUI in Machine Manager that allows for complete customization without adding a bunch of GUI to machine code plumbing.
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > "I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part." - Not sure I understand that statement. My quill has a bit under 5" of travel, the knee has almost 20". The quill travel is adequate for any one tool, but on a given job, I will use tools that vary in length from 1" (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> >
> > I absolutely intend to look at what you're doing with C#, as that is my language of choice (at present.... :-)). In fact, I'm hoping to do my own UI for KMotionCNC in C# at some point. I'm glad to hear you will give scripting access to the internals. If that really would provide a way to do what I need without modifying Toms source code, that would be a nice way to go.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > Very interesting topic indeed.
> > >
> > > This is just a brain-dump, so take it with a grain....
> > >
> > >
> > > I once had an old Kondia knee mill I planned to retrofit to CNC. My plan was to use the quill for the primary Z and index the knee as needed to shift around the Z's envelope of motion. If this is all you need then perhaps you could use the Interpreter's User Callback to call for an index and simply update your current fixture offset(G54/55/56/etc...).
> > >
> > > In this manner you can leave your tool comps accurate.
> > >
> > >
> > >
> > > Other than that I cannot see a need to interpolate both z's. I also cannot think of a need to use the knee's marginally longer travel except the rare(rare being relative to the types of parts you might machine on a knee mill) occasion where you are contouring a very large part.
> > >
> > > Just because I cannot see a practical need does not mean that one does not exist, so please share a reason if you have one.
> > >
> > >
> > > As Tom stated, I would be using IronPython scripts in my Usercallback handler(because I am using the c# gcode interface in Machine Manager).
> > >
> > > In a script you have complete and dynamic access to all Dynomotion and application objects. This makes custom integrations like what you are after a breeze(without the need for modifying source, etc...).
> > >
> > > Good luck with solving your challenge.
> > >
> > > My 2c,
> > >
> > > Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > I think there are many ways to accomplish what you need.  You should go ahead and do it whichever way you feel most comfortable with.  It can't hurt anything to try.  But here are some thoughts anyway :}
> > > >  
> > > > Regarding swap axis: yes that was exactly what I was thinking.  I don't really buy the "atomic" argument as most everything in GCode is modal anyway: incremental mode vs absolute for example.  And also if the axes were incorrectly swapped, then the error would be something like moving the part up instead the tool down which would achieve almost the same thing anyway (I could think of worse things).
> > > >  
> > > > Regarding that one line of code change: I don't think that will do it.  I think I see about 2 dozen other areas you will need to modify.  If I understand your approach it is to make a change such that the selected Z tool length offset will be applied to the A axis instead of the Z axis.   Changing the current_a instead of current_z would confuse the Interpreter and not introduce the offset to the A axis as you desire.  The "current" positions are basically where the Interpreter thinks it is at in Interpreter Space.  The current position should differ from the absolute machine coordinates by any offsets. So ignoring all other offsets for a moment the relationship should be:
> > > >  
> > > > MachineZ = CurrentZ + tool_length_offset
> > > >  
> > > > So for example lets say the Interpreter DRO says the "current" position is 10 inches and we have a 1 inch tool_length_offset applied so the Machine Coordinates (ie distance from home switch) should be 11 inches. 
> > > >  
> > > > 11 = 10 + 1
> > > >  
> > > > Now lets say we want to change the tool offset from 1 to 2 inches.  Because the Machine didn't move the Machine coordinates remain the same so we must change the Interpreters current position to 9 to remain consistent:
> > > >  
> > > > 11 = 9 + 2
> > > >   
> > > > If you do a global search in the code for tool_length_offset you will find about 2 dozen places where this offset is used in regard to z calculations.  I think you will need to modify those places to affect the A axis instead.
> > > >  
> > > > Regarding putting A,X,Y in the tool table besides the existing Length (Z): again you are right it would require the exact same changes, or rather additions to the Interpreter.  Those 2 dozen locations would then need to modify X, Y, and A similar to what it does now with Z.  But the advantage would be the User would then have a choice what it was to offset by changing the tool table without having to modify/re-compile the code to affect another axis.
> > > >  
> > > > Regarding Macros: Yes we really need a way to run code on the PC to customize things to do the type of functionality Mach3 VB does.  But it isn't clear to me what would be the best process.  Brad seems to think Python would be the way to go.
> > > >  
> > > > This is more of a question: Is the tool offset alone really sufficient to know where is the best place to position the knee?  Doesn't the thickness of the stock also factor in?  For example the stock is a 1 ft cube and the tool is short and all you wish to do is mill the top surface flat.  Wouldn't you want to put the knee way down in that case?
> > > >  
> > > > You bring up lots of good points to stimulate discussion Ray.
> > > >  
> > > > Thanks
> > > > TK
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > I don't see another obvious way to do this that would not require modification to the interpreter, or leave the door open for misbehavior, by making tool comp a non-atomic operation. The application, as I understand it, MUST be involved in the process, as only it has access to the tool table. So, if I don't modify the interpreter, it seems to me I'd have to insert something into the G-code BEFORE the G43/G49 to tell it I'm about to change the Z offset (this would presumably do the axis swap), then insert something AFTER the G43/G49 to tell it to un-swap the axes. What I don't like about this is, interrupting the program in the middle of this sequence will leave the machine in a state where the next Z or A axis move will move the wrong axis - not good!
> > > >
> > > > Looking at the code, it seems remarkably straight-forward - settings->current_z is directly modified by the magnitude of the tool length comp. It appears to me doing nothing more than changing that to settings->current_a would do the trick. This also appears to be the ONLY code that knows or cares a G43 or G49 is being processed. when I get my hands on VS, I'll have to give it a try. I sure can't see why it would not work.
> > > >
> > > > I don't see how adding an A offset to the tool table would help - it would require the exact same change in the interpreter to make it work properly.
> > > >
> > > > I am surprised there appears to be no common way of doing what I'm trying to do. It's not like there aren't a whole lot of knee mills out there! Mach3 also does not support it (yet - I put it on Brians ToDo list!), which is why I've had to create my own M-macros to do tool comp instead of using G43/G49. The macros work just fine, and the only down-side is my code is not portable to other machines, but I don't really much care about that. This was trivial to handle in Mach3, since I have direct access to the tool table within the macros. I could do the same thing in KMotionCNC if I had the ability to access the tool table and pass arguments to M-macros, but it appears to me I have neither.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >  
> > > > > I suppose this would work.  But it would be better to find a way to do it so you don't need to custom modify the Interpreter for your machines.  I haven't looked at that code but if you aren't careful it might upset the relationship between Machine Coordinates and Interpreter Coordinates.  Basically the DRO values on the Screen (and GCode numbers) map to actual machine coordinates through a whole bunch of offsets including tool length offsets.  Then there are times when we need to re-sync the Interpreter back from Machine coordinates (after an MPG Jog for example).  So you must be sure to keep both transformation directions consistent.
> > > > >  
> > > > > It seems like what you are trying to do would be a common thing.  Do you know how it is commonly accomplished?
> > > > >  
> > > > > I was thinking that the fundamental issue is that there are two methods of moving the cutting tool toward the stock: move A up or Z down.  So to me an MCode switch to specify which will move might make sense and we already have that functionality.
> > > > >  
> > > > > Another thought would be to add an A offset to the tool table.  We've considered adding x,y offsets in the past as I think that would work well with routers that have multiple spindles.  Switching spindles could then be accomplished with a tool change which it what it really is.  Right now I think it is common to use work offsets to handle it.
> > > > >  
> > > > > Regards
> > > > > TK
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > >
> > > > >
> > > > >  
> > > > > Moving on.... I intend to use KMotionCNC, but I need to do some customizations, starting with tool changes and tool length compensation. Since I don't (yet) have a tool-changer, I need the program to pause so I can manually change the tool. I can't use G43/G49 to enable/disable length comp, since they will act on the Z axis, and I need tool length offsets applied to the A axis.
> > > > >
> > > > > A toolchange therefore requires several steps:
> > > > >
> > > > > 1) If tool length compensation is enabled, move the A axis (knee) to position 0.000 - think of this as a modified G49
> > > > > 2) Prompt the user to load the new tool
> > > > > 3) Execute an M6 Tn for the new tool
> > > > > 3) If tool length compensation is subsequently enabled, move the A axis (knee) to the position given by the length parameter for the current tool. Think of this as a modified G43.
> > > > >
> > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n) into the G-code.
> > > > >
> > > > > #3 is a no-brainer, just G-code.
> > > > >
> > > > > #1 and #3, it appears to me that by far the cleanest way to do this this is by modifying the G-code interpreter to change the G43/G49 behavior - more specifically, by modifying the function "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I can see some other, rather mickey-mouse ways to do it, but this seems the cleanest and most robust.
> > > > >
> > > > > Do I have this right?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>

Brad,

I'm afraid I'm not following you. Suppose I do what you suggest, and halfway through a job, I break a tool. So I replace it, but the length has now changed. How do I recover, unless I have one fixture per tool, and re-set the zero for that one fixture? Is that what you're suggesting?

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Ray,
>
>
>
> Bear with me as I get a little exhaustive in my problem solving thought
> trains.
>
>
>
> I do not believe there would be any maintenance of the offsets, once you
> had your original offset dialed in, the others would be offset a specific
> distance from each other based on the safe travel of your quill.
>
> Of course this only works if you are like me and do not like adjusting your
> offset every time you make a part and make your table z0.0 and program your
> part accordingly.
>
>
>
> Either way, it was just a temporary suggestion, when MM is released you will
> be able to handle this with ease via User callbacks + scripts with access to
> all required objects, including tool table.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Sunday, November 06, 2011 11:01 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Customizing Tool Changes
>
>
>
>
>
> Brad,
>
> I considered that approach a long time ago, but ruled it out pretty quickly.
> I think managing a slew of offsets like that would be a real PITA, and would
> REALLY complicate G-code generation, having to figure out which fixture to
> use when. I don't have any single jobs that need more than about 4-1/2" of
> travel, but I do have several that use pretty much all the quill travel
> between clearance height and drilling deep holes. I think you'd pretty much
> have to apply a different offset per tool, but I don't know the tool lengths
> when I generate the G-code. And, break a tool, and you've broken your code
> too.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "bradodarb" <bradodarb@> wrote:
> >
> > Hello Ray,
> >
> > Well yours must be bigger than mine was... My quill was in the
> neighborhood of 6" and although my knee's ways were around 20" the
> knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
> >
> > Still, what do you think about just indexing the knee to different "work
> offsets"? This would not involve any 'axis swapping', just command a single
> axis move from the user callback and update whatever work offset you are
> currently using(G54/55/56/etc...)
> >
> > With this approach you would only ever be interpreting g code using the
> quill. You could probably implement this behavior right now as -is by using
> custom M codes to handle positioning the knee to preset levels in
> conjunction with setting up 3-4 work offsets to match these presets.
> >
> > As an example:
> >
> > G54 = X0.0 Y0.0 Z0.0
> > G55 = X0.0 Y0.0 Z-4.0
> > G56 = X0.0 Y0.0 Z-8.0
> > G57 = X0.0 Y0.0 Z-12.0
> >
> > Or something to that effect-I'm certain you get the idea.
> >
> >
> > Looking forward to working with other devs on the c#. There is already a
> rich framework for GUI in Machine Manager that allows for complete
> customization without adding a bunch of GUI to machine code plumbing.
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > "I also cannot think of a need to use the knee's marginally longer
> travel except the rare(rare being relative to the types of parts you might
> machine on a knee mill) occasion where you are contouring a very large
> part." - Not sure I understand that statement. My quill has a bit under 5"
> of travel, the knee has almost 20". The quill travel is adequate for any one
> tool, but on a given job, I will use tools that vary in length from 1"
> (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> > >
> > > I absolutely intend to look at what you're doing with C#, as that is my
> language of choice (at present.... :-)). In fact, I'm hoping to do my own UI
> for KMotionCNC in C# at some point. I'm glad to hear you will give scripting
> access to the internals. If that really would provide a way to do what I
> need without modifying Toms source code, that would be a nice way to go.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> , "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Very interesting topic indeed.
> > > >
> > > > This is just a brain-dump, so take it with a grain....
> > > >
> > > >
> > > > I once had an old Kondia knee mill I planned to retrofit to CNC. My
> plan was to use the quill for the primary Z and index the knee as needed to
> shift around the Z's envelope of motion. If this is all you need then
> perhaps you could use the Interpreter's User Callback to call for an index
> and simply update your current fixture offset(G54/55/56/etc...).
> > > >
> > > > In this manner you can leave your tool comps accurate.
> > > >
> > > >
> > > >
> > > > Other than that I cannot see a need to interpolate both z's. I also
> cannot think of a need to use the knee's marginally longer travel except the
> rare(rare being relative to the types of parts you might machine on a knee
> mill) occasion where you are contouring a very large part.
> > > >
> > > > Just because I cannot see a practical need does not mean that one does
> not exist, so please share a reason if you have one.
> > > >
> > > >
> > > > As Tom stated, I would be using IronPython scripts in my Usercallback
> handler(because I am using the c# gcode interface in Machine Manager).
> > > >
> > > > In a script you have complete and dynamic access to all Dynomotion and
> application objects. This makes custom integrations like what you are after
> a breeze(without the need for modifying source, etc...).
> > > >
> > > > Good luck with solving your challenge.
> > > >
> > > > My 2c,
> > > >
> > > > Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > > Â
> > > > > I think there are many ways to accomplish what you need. You
> should go ahead and do it whichever way you feel most comfortable with. It
> can't hurt anything to try. But here are some thoughts anyway :}
> > > > > Â
> > > > > Regarding swap axis: yes that was exactly what I was thinking. I
> don't really buy the "atomic" argument as most everything in GCode is modal
> anyway: incremental mode vs absolute for example. And also if the axes
> were incorrectly swapped, then the error would be something like moving the
> part up instead the tool down which would achieve almost the same thing
> anyway (I could think of worse things).
> > > > > Â
> > > > > Regarding that one line of code change: I don't think that will do
> it. I think I see about 2 dozen other areas you will need to modify. If
> I understand your approach it is to make a change such that the selected Z
> tool length offset will be applied to the A axis instead of the Z axis. Â
> Changing the current_a instead of current_z would confuse the Interpreter
> and not introduce the offset to the A axis as you desire. The "current"
> positions are basically where the Interpreter thinks it is at in
> Interpreter Space. The current position should differ from the absolute
> machine coordinates by any offsets. So ignoring all other offsets for a
> moment the relationship should be:
> > > > > Â
> > > > > MachineZ =Â CurrentZ + tool_length_offset
> > > > > Â
> > > > > So for example lets say the Interpreter DRO says the "current"
> position is 10 inches and we have a 1 inch tool_length_offset applied so
> the Machine Coordinates (ie distance from home switch) should be 11
> inches.Â
> > > > > Â
> > > > > 11Â =Â 10 + 1
> > > > > Â
> > > > > Now lets say we want to change the tool offset from 1 to 2 inches.Â
> Because the Machine didn't move the Machine coordinates remain the same so
> we must change the Interpreters current position to 9 to remain consistent:
> > > > > Â
> > > > > 11Â =Â 9 + 2
> > > > > Â Â
> > > > > If you do a global search in the code for tool_length_offset you
> will find about 2 dozen places where this offset is used in regard to z
> calculations. I think you will need to modify those places to affect the A
> axis instead.
> > > > > Â
> > > > > Regarding putting A,X,Y in the tool table besides the existing
> Length (Z): again you are right it would require the exact same changes, or
> rather additions to the Interpreter. Those 2 dozen locations would then
> need to modify X, Y, and A similar to what it does now with Z. But the
> advantage would be the User would then have a choice what it was to offset
> by changing the tool table without having to modify/re-compile the code to
> affect another axis.
> > > > > Â
> > > > > Regarding Macros: Yes we really need a way to run code on the PC to
> customize things to do the type of functionality Mach3 VB does. But it
> isn't clear to me what would be the best process. Brad seems to think
> Python would be the way to go.
> > > > > Â
> > > > > This is more of a question: Is the tool offset alone really
> sufficient to know where is the best place to position the knee?  Doesn't
> the thickness of the stock also factor in? For example the stock is a 1 ft
> cube and the tool is short and all you wish to do is mill the top surface
> flat. Wouldn't you want to put the knee way down in that case?
> > > > > Â
> > > > > You bring up lots of good points to stimulate discussion Ray.
> > > > > Â
> > > > > Thanks
> > > > > TK
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
>
> > > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > > >
> > > > >
> > > > > Â
> > > > > Tom,
> > > > >
> > > > > I don't see another obvious way to do this that would not require
> modification to the interpreter, or leave the door open for misbehavior, by
> making tool comp a non-atomic operation. The application, as I understand
> it, MUST be involved in the process, as only it has access to the tool
> table. So, if I don't modify the interpreter, it seems to me I'd have to
> insert something into the G-code BEFORE the G43/G49 to tell it I'm about to
> change the Z offset (this would presumably do the axis swap), then insert
> something AFTER the G43/G49 to tell it to un-swap the axes. What I don't
> like about this is, interrupting the program in the middle of this sequence
> will leave the machine in a state where the next Z or A axis move will move
> the wrong axis - not good!
> > > > >
> > > > > Looking at the code, it seems remarkably straight-forward -
> settings->current_z is directly modified by the magnitude of the tool length
> comp. It appears to me doing nothing more than changing that to
> settings->current_a would do the trick. This also appears to be the ONLY
> code that knows or cares a G43 or G49 is being processed. when I get my
> hands on VS, I'll have to give it a try. I sure can't see why it would not
> work.
> > > > >
> > > > > I don't see how adding an A offset to the tool table would help - it
> would require the exact same change in the interpreter to make it work
> properly.
> > > > >
> > > > > I am surprised there appears to be no common way of doing what I'm
> trying to do. It's not like there aren't a whole lot of knee mills out
> there! Mach3 also does not support it (yet - I put it on Brians ToDo list!),
> which is why I've had to create my own M-macros to do tool comp instead of
> using G43/G49. The macros work just fine, and the only down-side is my code
> is not portable to other machines, but I don't really much care about that.
> This was trivial to handle in Mach3, since I have direct access to the tool
> table within the macros. I could do the same thing in KMotionCNC if I had
> the ability to access the tool table and pass arguments to M-macros, but it
> appears to me I have neither.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÂÂ
> > > > > > I suppose this would work. But it would be better to find a
> way to do it so you don't need to custom modify the Interpreter for your
> machines. I haven't looked at that code but if you aren't careful it
> might upset the relationship between Machine Coordinates and Interpreter
> Coordinates. Basically the DRO values on the Screen (and GCode numbers)
> map to actual machine coordinates through a whole bunch of offsets including
> tool length offsets. Then there are times when we need to re-sync the
> Interpreter back from Machine coordinates (after an MPG Jog for example).ÂÂ
> So you must be sure to keep both transformation directions consistent.
> > > > > > ÂÂ
> > > > > > It seems like what you are trying to do would be a common
> thing. Do you know how it is commonly accomplished?
> > > > > > ÂÂ
> > > > > > I was thinking that the fundamental issue is that there are two
> methods of moving the cutting tool toward the stock: move A up or Z down.ÂÂ
> So to me an MCode switch to specify which will move might make sense and we
> already have that functionality.
> > > > > > ÂÂ
> > > > > > Another thought would be to add an A offset to the tool table.ÂÂ
> We've considered adding x,y offsets in the past as I think that would work
> well with routers that have multiple spindles. Switching spindles could
> then be accomplished with a tool change which it what it really is.ÂÂ
> Right now I think it is common to use work offsets to handle it.
> > > > > > ÂÂ
> > > > > > Regards
> > > > > > TK
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > > >
> > > > > >
> > > > > > ÂÂ
> > > > > > Moving on.... I intend to use KMotionCNC, but I need to do some
> customizations, starting with tool changes and tool length compensation.
> Since I don't (yet) have a tool-changer, I need the program to pause so I
> can manually change the tool. I can't use G43/G49 to enable/disable length
> comp, since they will act on the Z axis, and I need tool length offsets
> applied to the A axis.
> > > > > >
> > > > > > A toolchange therefore requires several steps:
> > > > > >
> > > > > > 1) If tool length compensation is enabled, move the A axis (knee)
> to position 0.000 - think of this as a modified G49
> > > > > > 2) Prompt the user to load the new tool
> > > > > > 3) Execute an M6 Tn for the new tool
> > > > > > 3) If tool length compensation is subsequently enabled, move the A
> axis (knee) to the position given by the length parameter for the current
> tool. Think of this as a modified G43.
> > > > > >
> > > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n)
> into the G-code.
> > > > > >
> > > > > > #3 is a no-brainer, just G-code.
> > > > > >
> > > > > > #1 and #3, it appears to me that by far the cleanest way to do
> this this is by modifying the G-code interpreter to change the G43/G49
> behavior - more specifically, by modifying the function
> "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I
> can see some other, rather mickey-mouse ways to do it, but this seems the
> cleanest and most robust.
> > > > > >
> > > > > > Do I have this right?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>

BTW - (and this is no doubt obvious by now....) I am NO expert on this! This is the only CNC machine I've ever operated, I am totally self-taught, and I've only been at it a couple of years. So, I may well be doing things completely wrong. I just know what I do does work well, but I could easily believe there's a better way.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Ray,
>
>
>
> Bear with me as I get a little exhaustive in my problem solving thought
> trains.
>
>
>
> I do not believe there would be any maintenance of the offsets, once you
> had your original offset dialed in, the others would be offset a specific
> distance from each other based on the safe travel of your quill.
>
> Of course this only works if you are like me and do not like adjusting your
> offset every time you make a part and make your table z0.0 and program your
> part accordingly.
>
>
>
> Either way, it was just a temporary suggestion, when MM is released you will
> be able to handle this with ease via User callbacks + scripts with access to
> all required objects, including tool table.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Sunday, November 06, 2011 11:01 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Customizing Tool Changes
>
>
>
>
>
> Brad,
>
> I considered that approach a long time ago, but ruled it out pretty quickly.
> I think managing a slew of offsets like that would be a real PITA, and would
> REALLY complicate G-code generation, having to figure out which fixture to
> use when. I don't have any single jobs that need more than about 4-1/2" of
> travel, but I do have several that use pretty much all the quill travel
> between clearance height and drilling deep holes. I think you'd pretty much
> have to apply a different offset per tool, but I don't know the tool lengths
> when I generate the G-code. And, break a tool, and you've broken your code
> too.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "bradodarb" <bradodarb@> wrote:
> >
> > Hello Ray,
> >
> > Well yours must be bigger than mine was... My quill was in the
> neighborhood of 6" and although my knee's ways were around 20" the
> knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
> >
> > Still, what do you think about just indexing the knee to different "work
> offsets"? This would not involve any 'axis swapping', just command a single
> axis move from the user callback and update whatever work offset you are
> currently using(G54/55/56/etc...)
> >
> > With this approach you would only ever be interpreting g code using the
> quill. You could probably implement this behavior right now as -is by using
> custom M codes to handle positioning the knee to preset levels in
> conjunction with setting up 3-4 work offsets to match these presets.
> >
> > As an example:
> >
> > G54 = X0.0 Y0.0 Z0.0
> > G55 = X0.0 Y0.0 Z-4.0
> > G56 = X0.0 Y0.0 Z-8.0
> > G57 = X0.0 Y0.0 Z-12.0
> >
> > Or something to that effect-I'm certain you get the idea.
> >
> >
> > Looking forward to working with other devs on the c#. There is already a
> rich framework for GUI in Machine Manager that allows for complete
> customization without adding a bunch of GUI to machine code plumbing.
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > "I also cannot think of a need to use the knee's marginally longer
> travel except the rare(rare being relative to the types of parts you might
> machine on a knee mill) occasion where you are contouring a very large
> part." - Not sure I understand that statement. My quill has a bit under 5"
> of travel, the knee has almost 20". The quill travel is adequate for any one
> tool, but on a given job, I will use tools that vary in length from 1"
> (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> > >
> > > I absolutely intend to look at what you're doing with C#, as that is my
> language of choice (at present.... :-)). In fact, I'm hoping to do my own UI
> for KMotionCNC in C# at some point. I'm glad to hear you will give scripting
> access to the internals. If that really would provide a way to do what I
> need without modifying Toms source code, that would be a nice way to go.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> , "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Very interesting topic indeed.
> > > >
> > > > This is just a brain-dump, so take it with a grain....
> > > >
> > > >
> > > > I once had an old Kondia knee mill I planned to retrofit to CNC. My
> plan was to use the quill for the primary Z and index the knee as needed to
> shift around the Z's envelope of motion. If this is all you need then
> perhaps you could use the Interpreter's User Callback to call for an index
> and simply update your current fixture offset(G54/55/56/etc...).
> > > >
> > > > In this manner you can leave your tool comps accurate.
> > > >
> > > >
> > > >
> > > > Other than that I cannot see a need to interpolate both z's. I also
> cannot think of a need to use the knee's marginally longer travel except the
> rare(rare being relative to the types of parts you might machine on a knee
> mill) occasion where you are contouring a very large part.
> > > >
> > > > Just because I cannot see a practical need does not mean that one does
> not exist, so please share a reason if you have one.
> > > >
> > > >
> > > > As Tom stated, I would be using IronPython scripts in my Usercallback
> handler(because I am using the c# gcode interface in Machine Manager).
> > > >
> > > > In a script you have complete and dynamic access to all Dynomotion and
> application objects. This makes custom integrations like what you are after
> a breeze(without the need for modifying source, etc...).
> > > >
> > > > Good luck with solving your challenge.
> > > >
> > > > My 2c,
> > > >
> > > > Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > > Â
> > > > > I think there are many ways to accomplish what you need. You
> should go ahead and do it whichever way you feel most comfortable with. It
> can't hurt anything to try. But here are some thoughts anyway :}
> > > > > Â
> > > > > Regarding swap axis: yes that was exactly what I was thinking. I
> don't really buy the "atomic" argument as most everything in GCode is modal
> anyway: incremental mode vs absolute for example. And also if the axes
> were incorrectly swapped, then the error would be something like moving the
> part up instead the tool down which would achieve almost the same thing
> anyway (I could think of worse things).
> > > > > Â
> > > > > Regarding that one line of code change: I don't think that will do
> it. I think I see about 2 dozen other areas you will need to modify. If
> I understand your approach it is to make a change such that the selected Z
> tool length offset will be applied to the A axis instead of the Z axis. Â
> Changing the current_a instead of current_z would confuse the Interpreter
> and not introduce the offset to the A axis as you desire. The "current"
> positions are basically where the Interpreter thinks it is at in
> Interpreter Space. The current position should differ from the absolute
> machine coordinates by any offsets. So ignoring all other offsets for a
> moment the relationship should be:
> > > > > Â
> > > > > MachineZ =Â CurrentZ + tool_length_offset
> > > > > Â
> > > > > So for example lets say the Interpreter DRO says the "current"
> position is 10 inches and we have a 1 inch tool_length_offset applied so
> the Machine Coordinates (ie distance from home switch) should be 11
> inches.Â
> > > > > Â
> > > > > 11Â =Â 10 + 1
> > > > > Â
> > > > > Now lets say we want to change the tool offset from 1 to 2 inches.Â
> Because the Machine didn't move the Machine coordinates remain the same so
> we must change the Interpreters current position to 9 to remain consistent:
> > > > > Â
> > > > > 11Â =Â 9 + 2
> > > > > Â Â
> > > > > If you do a global search in the code for tool_length_offset you
> will find about 2 dozen places where this offset is used in regard to z
> calculations. I think you will need to modify those places to affect the A
> axis instead.
> > > > > Â
> > > > > Regarding putting A,X,Y in the tool table besides the existing
> Length (Z): again you are right it would require the exact same changes, or
> rather additions to the Interpreter. Those 2 dozen locations would then
> need to modify X, Y, and A similar to what it does now with Z. But the
> advantage would be the User would then have a choice what it was to offset
> by changing the tool table without having to modify/re-compile the code to
> affect another axis.
> > > > > Â
> > > > > Regarding Macros: Yes we really need a way to run code on the PC to
> customize things to do the type of functionality Mach3 VB does. But it
> isn't clear to me what would be the best process. Brad seems to think
> Python would be the way to go.
> > > > > Â
> > > > > This is more of a question: Is the tool offset alone really
> sufficient to know where is the best place to position the knee?  Doesn't
> the thickness of the stock also factor in? For example the stock is a 1 ft
> cube and the tool is short and all you wish to do is mill the top surface
> flat. Wouldn't you want to put the knee way down in that case?
> > > > > Â
> > > > > You bring up lots of good points to stimulate discussion Ray.
> > > > > Â
> > > > > Thanks
> > > > > TK
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
>
> > > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > > >
> > > > >
> > > > > Â
> > > > > Tom,
> > > > >
> > > > > I don't see another obvious way to do this that would not require
> modification to the interpreter, or leave the door open for misbehavior, by
> making tool comp a non-atomic operation. The application, as I understand
> it, MUST be involved in the process, as only it has access to the tool
> table. So, if I don't modify the interpreter, it seems to me I'd have to
> insert something into the G-code BEFORE the G43/G49 to tell it I'm about to
> change the Z offset (this would presumably do the axis swap), then insert
> something AFTER the G43/G49 to tell it to un-swap the axes. What I don't
> like about this is, interrupting the program in the middle of this sequence
> will leave the machine in a state where the next Z or A axis move will move
> the wrong axis - not good!
> > > > >
> > > > > Looking at the code, it seems remarkably straight-forward -
> settings->current_z is directly modified by the magnitude of the tool length
> comp. It appears to me doing nothing more than changing that to
> settings->current_a would do the trick. This also appears to be the ONLY
> code that knows or cares a G43 or G49 is being processed. when I get my
> hands on VS, I'll have to give it a try. I sure can't see why it would not
> work.
> > > > >
> > > > > I don't see how adding an A offset to the tool table would help - it
> would require the exact same change in the interpreter to make it work
> properly.
> > > > >
> > > > > I am surprised there appears to be no common way of doing what I'm
> trying to do. It's not like there aren't a whole lot of knee mills out
> there! Mach3 also does not support it (yet - I put it on Brians ToDo list!),
> which is why I've had to create my own M-macros to do tool comp instead of
> using G43/G49. The macros work just fine, and the only down-side is my code
> is not portable to other machines, but I don't really much care about that.
> This was trivial to handle in Mach3, since I have direct access to the tool
> table within the macros. I could do the same thing in KMotionCNC if I had
> the ability to access the tool table and pass arguments to M-macros, but it
> appears to me I have neither.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÂÂ
> > > > > > I suppose this would work. But it would be better to find a
> way to do it so you don't need to custom modify the Interpreter for your
> machines. I haven't looked at that code but if you aren't careful it
> might upset the relationship between Machine Coordinates and Interpreter
> Coordinates. Basically the DRO values on the Screen (and GCode numbers)
> map to actual machine coordinates through a whole bunch of offsets including
> tool length offsets. Then there are times when we need to re-sync the
> Interpreter back from Machine coordinates (after an MPG Jog for example).ÂÂ
> So you must be sure to keep both transformation directions consistent.
> > > > > > ÂÂ
> > > > > > It seems like what you are trying to do would be a common
> thing. Do you know how it is commonly accomplished?
> > > > > > ÂÂ
> > > > > > I was thinking that the fundamental issue is that there are two
> methods of moving the cutting tool toward the stock: move A up or Z down.ÂÂ
> So to me an MCode switch to specify which will move might make sense and we
> already have that functionality.
> > > > > > ÂÂ
> > > > > > Another thought would be to add an A offset to the tool table.ÂÂ
> We've considered adding x,y offsets in the past as I think that would work
> well with routers that have multiple spindles. Switching spindles could
> then be accomplished with a tool change which it what it really is.ÂÂ
> Right now I think it is common to use work offsets to handle it.
> > > > > > ÂÂ
> > > > > > Regards
> > > > > > TK
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > > ÂÂ
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > > >
> > > > > >
> > > > > > ÂÂ
> > > > > > Moving on.... I intend to use KMotionCNC, but I need to do some
> customizations, starting with tool changes and tool length compensation.
> Since I don't (yet) have a tool-changer, I need the program to pause so I
> can manually change the tool. I can't use G43/G49 to enable/disable length
> comp, since they will act on the Z axis, and I need tool length offsets
> applied to the A axis.
> > > > > >
> > > > > > A toolchange therefore requires several steps:
> > > > > >
> > > > > > 1) If tool length compensation is enabled, move the A axis (knee)
> to position 0.000 - think of this as a modified G49
> > > > > > 2) Prompt the user to load the new tool
> > > > > > 3) Execute an M6 Tn for the new tool
> > > > > > 3) If tool length compensation is subsequently enabled, move the A
> axis (knee) to the position given by the length parameter for the current
> tool. Think of this as a modified G43.
> > > > > >
> > > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n)
> into the G-code.
> > > > > >
> > > > > > #3 is a no-brainer, just G-code.
> > > > > >
> > > > > > #1 and #3, it appears to me that by far the cleanest way to do
> this this is by modifying the G-code interpreter to change the G43/G49
> behavior - more specifically, by modifying the function
> "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I
> can see some other, rather mickey-mouse ways to do it, but this seems the
> cleanest and most robust.
> > > > > >
> > > > > > Do I have this right?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Again this is just an exercise, so lets pick it apart.

No, not on fixture per tool.

The basic concept of what I am suggesting is to assign ranges of tools to different offsets based on their length.

So tools 0-4" in length are zeroed to G54, 4-8" are G55 and 8-12" are G56.

(Assuming you create 4" increments between the offsets)

If you are using table==z0.0 then there is nothing left to do, otherwise use temporary part offset for material thickness if you prefer z0.0 at the top of the part.

Make sense? Poke any holes if I am overlooking something, even if this approach is not ideal I would like to see if it is viable.

-Brad Murry

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> I'm afraid I'm not following you. Suppose I do what you suggest, and halfway through a job, I break a tool. So I replace it, but the length has now changed. How do I recover, unless I have one fixture per tool, and re-set the zero for that one fixture? Is that what you're suggesting?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > Ray,
> >
> >
> >
> > Bear with me as I get a little exhaustive in my problem solving thought
> > trains.
> >
> >
> >
> > I do not believe there would be any maintenance of the offsets, once you
> > had your original offset dialed in, the others would be offset a specific
> > distance from each other based on the safe travel of your quill.
> >
> > Of course this only works if you are like me and do not like adjusting your
> > offset every time you make a part and make your table z0.0 and program your
> > part accordingly.
> >
> >
> >
> > Either way, it was just a temporary suggestion, when MM is released you will
> > be able to handle this with ease via User callbacks + scripts with access to
> > all required objects, including tool table.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Sunday, November 06, 2011 11:01 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: Customizing Tool Changes
> >
> >
> >
> >
> >
> > Brad,
> >
> > I considered that approach a long time ago, but ruled it out pretty quickly.
> > I think managing a slew of offsets like that would be a real PITA, and would
> > REALLY complicate G-code generation, having to figure out which fixture to
> > use when. I don't have any single jobs that need more than about 4-1/2" of
> > travel, but I do have several that use pretty much all the quill travel
> > between clearance height and drilling deep holes. I think you'd pretty much
> > have to apply a different offset per tool, but I don't know the tool lengths
> > when I generate the G-code. And, break a tool, and you've broken your code
> > too.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > "bradodarb" <bradodarb@> wrote:
> > >
> > > Hello Ray,
> > >
> > > Well yours must be bigger than mine was... My quill was in the
> > neighborhood of 6" and although my knee's ways were around 20" the
> > knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
> > >
> > > Still, what do you think about just indexing the knee to different "work
> > offsets"? This would not involve any 'axis swapping', just command a single
> > axis move from the user callback and update whatever work offset you are
> > currently using(G54/55/56/etc...)
> > >
> > > With this approach you would only ever be interpreting g code using the
> > quill. You could probably implement this behavior right now as -is by using
> > custom M codes to handle positioning the knee to preset levels in
> > conjunction with setting up 3-4 work offsets to match these presets.
> > >
> > > As an example:
> > >
> > > G54 = X0.0 Y0.0 Z0.0
> > > G55 = X0.0 Y0.0 Z-4.0
> > > G56 = X0.0 Y0.0 Z-8.0
> > > G57 = X0.0 Y0.0 Z-12.0
> > >
> > > Or something to that effect-I'm certain you get the idea.
> > >
> > >
> > > Looking forward to working with other devs on the c#. There is already a
> > rich framework for GUI in Machine Manager that allows for complete
> > customization without adding a bunch of GUI to machine code plumbing.
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > > >
> > > > Brad,
> > > >
> > > > "I also cannot think of a need to use the knee's marginally longer
> > travel except the rare(rare being relative to the types of parts you might
> > machine on a knee mill) occasion where you are contouring a very large
> > part." - Not sure I understand that statement. My quill has a bit under 5"
> > of travel, the knee has almost 20". The quill travel is adequate for any one
> > tool, but on a given job, I will use tools that vary in length from 1"
> > (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> > > >
> > > > I absolutely intend to look at what you're doing with C#, as that is my
> > language of choice (at present.... :-)). In fact, I'm hoping to do my own UI
> > for KMotionCNC in C# at some point. I'm glad to hear you will give scripting
> > access to the internals. If that really would provide a way to do what I
> > need without modifying Toms source code, that would be a nice way to go.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > , "bradodarb" <bradodarb@> wrote:
> > > > >
> > > > > Very interesting topic indeed.
> > > > >
> > > > > This is just a brain-dump, so take it with a grain....
> > > > >
> > > > >
> > > > > I once had an old Kondia knee mill I planned to retrofit to CNC. My
> > plan was to use the quill for the primary Z and index the knee as needed to
> > shift around the Z's envelope of motion. If this is all you need then
> > perhaps you could use the Interpreter's User Callback to call for an index
> > and simply update your current fixture offset(G54/55/56/etc...).
> > > > >
> > > > > In this manner you can leave your tool comps accurate.
> > > > >
> > > > >
> > > > >
> > > > > Other than that I cannot see a need to interpolate both z's. I also
> > cannot think of a need to use the knee's marginally longer travel except the
> > rare(rare being relative to the types of parts you might machine on a knee
> > mill) occasion where you are contouring a very large part.
> > > > >
> > > > > Just because I cannot see a practical need does not mean that one does
> > not exist, so please share a reason if you have one.
> > > > >
> > > > >
> > > > > As Tom stated, I would be using IronPython scripts in my Usercallback
> > handler(because I am using the c# gcode interface in Machine Manager).
> > > > >
> > > > > In a script you have complete and dynamic access to all Dynomotion and
> > application objects. This makes custom integrations like what you are after
> > a breeze(without the need for modifying source, etc...).
> > > > >
> > > > > Good luck with solving your challenge.
> > > > >
> > > > > My 2c,
> > > > >
> > > > > Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > Â
> > > > > > I think there are many ways to accomplish what you need. You
> > should go ahead and do it whichever way you feel most comfortable with. It
> > can't hurt anything to try. But here are some thoughts anyway :}
> > > > > > Â
> > > > > > Regarding swap axis: yes that was exactly what I was thinking. I
> > don't really buy the "atomic" argument as most everything in GCode is modal
> > anyway: incremental mode vs absolute for example. And also if the axes
> > were incorrectly swapped, then the error would be something like moving the
> > part up instead the tool down which would achieve almost the same thing
> > anyway (I could think of worse things).
> > > > > > Â
> > > > > > Regarding that one line of code change: I don't think that will do
> > it. I think I see about 2 dozen other areas you will need to modify. If
> > I understand your approach it is to make a change such that the selected Z
> > tool length offset will be applied to the A axis instead of the Z axis. Â
> > Changing the current_a instead of current_z would confuse the Interpreter
> > and not introduce the offset to the A axis as you desire. The "current"
> > positions are basically where the Interpreter thinks it is at in
> > Interpreter Space. The current position should differ from the absolute
> > machine coordinates by any offsets. So ignoring all other offsets for a
> > moment the relationship should be:
> > > > > > Â
> > > > > > MachineZ =Â CurrentZ + tool_length_offset
> > > > > > Â
> > > > > > So for example lets say the Interpreter DRO says the "current"
> > position is 10 inches and we have a 1 inch tool_length_offset applied so
> > the Machine Coordinates (ie distance from home switch) should be 11
> > inches.Â
> > > > > > Â
> > > > > > 11Â =Â 10 + 1
> > > > > > Â
> > > > > > Now lets say we want to change the tool offset from 1 to 2 inches.Â
> > Because the Machine didn't move the Machine coordinates remain the same so
> > we must change the Interpreters current position to 9 to remain consistent:
> > > > > > Â
> > > > > > 11Â =Â 9 + 2
> > > > > > Â Â
> > > > > > If you do a global search in the code for tool_length_offset you
> > will find about 2 dozen places where this offset is used in regard to z
> > calculations. I think you will need to modify those places to affect the A
> > axis instead.
> > > > > > Â
> > > > > > Regarding putting A,X,Y in the tool table besides the existing
> > Length (Z): again you are right it would require the exact same changes, or
> > rather additions to the Interpreter. Those 2 dozen locations would then
> > need to modify X, Y, and A similar to what it does now with Z. But the
> > advantage would be the User would then have a choice what it was to offset
> > by changing the tool table without having to modify/re-compile the code to
> > affect another axis.
> > > > > > Â
> > > > > > Regarding Macros: Yes we really need a way to run code on the PC to
> > customize things to do the type of functionality Mach3 VB does. But it
> > isn't clear to me what would be the best process. Brad seems to think
> > Python would be the way to go.
> > > > > > Â
> > > > > > This is more of a question: Is the tool offset alone really
> > sufficient to know where is the best place to position the knee?  Doesn't
> > the thickness of the stock also factor in? For example the stock is a 1 ft
> > cube and the tool is short and all you wish to do is mill the top surface
> > flat. Wouldn't you want to put the knee way down in that case?
> > > > > > Â
> > > > > > You bring up lots of good points to stimulate discussion Ray.
> > > > > > Â
> > > > > > Thanks
> > > > > > TK
> > > > > >
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> >
> > > > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > > > >
> > > > > >
> > > > > > Â
> > > > > > Tom,
> > > > > >
> > > > > > I don't see another obvious way to do this that would not require
> > modification to the interpreter, or leave the door open for misbehavior, by
> > making tool comp a non-atomic operation. The application, as I understand
> > it, MUST be involved in the process, as only it has access to the tool
> > table. So, if I don't modify the interpreter, it seems to me I'd have to
> > insert something into the G-code BEFORE the G43/G49 to tell it I'm about to
> > change the Z offset (this would presumably do the axis swap), then insert
> > something AFTER the G43/G49 to tell it to un-swap the axes. What I don't
> > like about this is, interrupting the program in the middle of this sequence
> > will leave the machine in a state where the next Z or A axis move will move
> > the wrong axis - not good!
> > > > > >
> > > > > > Looking at the code, it seems remarkably straight-forward -
> > settings->current_z is directly modified by the magnitude of the tool length
> > comp. It appears to me doing nothing more than changing that to
> > settings->current_a would do the trick. This also appears to be the ONLY
> > code that knows or cares a G43 or G49 is being processed. when I get my
> > hands on VS, I'll have to give it a try. I sure can't see why it would not
> > work.
> > > > > >
> > > > > > I don't see how adding an A offset to the tool table would help - it
> > would require the exact same change in the interpreter to make it work
> > properly.
> > > > > >
> > > > > > I am surprised there appears to be no common way of doing what I'm
> > trying to do. It's not like there aren't a whole lot of knee mills out
> > there! Mach3 also does not support it (yet - I put it on Brians ToDo list!),
> > which is why I've had to create my own M-macros to do tool comp instead of
> > using G43/G49. The macros work just fine, and the only down-side is my code
> > is not portable to other machines, but I don't really much care about that.
> > This was trivial to handle in Mach3, since I have direct access to the tool
> > table within the macros. I could do the same thing in KMotionCNC if I had
> > the ability to access the tool table and pass arguments to M-macros, but it
> > appears to me I have neither.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > > ÂÂ
> > > > > > > I suppose this would work. But it would be better to find a
> > way to do it so you don't need to custom modify the Interpreter for your
> > machines. I haven't looked at that code but if you aren't careful it
> > might upset the relationship between Machine Coordinates and Interpreter
> > Coordinates. Basically the DRO values on the Screen (and GCode numbers)
> > map to actual machine coordinates through a whole bunch of offsets including
> > tool length offsets. Then there are times when we need to re-sync the
> > Interpreter back from Machine coordinates (after an MPG Jog for example).ÂÂ
> > So you must be sure to keep both transformation directions consistent.
> > > > > > > ÂÂ
> > > > > > > It seems like what you are trying to do would be a common
> > thing. Do you know how it is commonly accomplished?
> > > > > > > ÂÂ
> > > > > > > I was thinking that the fundamental issue is that there are two
> > methods of moving the cutting tool toward the stock: move A up or Z down.ÂÂ
> > So to me an MCode switch to specify which will move might make sense and we
> > already have that functionality.
> > > > > > > ÂÂ
> > > > > > > Another thought would be to add an A offset to the tool table.ÂÂ
> > We've considered adding x,y offsets in the past as I think that would work
> > well with routers that have multiple spindles. Switching spindles could
> > then be accomplished with a tool change which it what it really is.ÂÂ
> > Right now I think it is common to use work offsets to handle it.
> > > > > > > ÂÂ
> > > > > > > Regards
> > > > > > > TK
> > > > > > > ÂÂ
> > > > > > > ÂÂ
> > > > > > > ÂÂ
> > > > > > > ÂÂ
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > > > >
> > > > > > >
> > > > > > > ÂÂ
> > > > > > > Moving on.... I intend to use KMotionCNC, but I need to do some
> > customizations, starting with tool changes and tool length compensation.
> > Since I don't (yet) have a tool-changer, I need the program to pause so I
> > can manually change the tool. I can't use G43/G49 to enable/disable length
> > comp, since they will act on the Z axis, and I need tool length offsets
> > applied to the A axis.
> > > > > > >
> > > > > > > A toolchange therefore requires several steps:
> > > > > > >
> > > > > > > 1) If tool length compensation is enabled, move the A axis (knee)
> > to position 0.000 - think of this as a modified G49
> > > > > > > 2) Prompt the user to load the new tool
> > > > > > > 3) Execute an M6 Tn for the new tool
> > > > > > > 3) If tool length compensation is subsequently enabled, move the A
> > axis (knee) to the position given by the length parameter for the current
> > tool. Think of this as a modified G43.
> > > > > > >
> > > > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n)
> > into the G-code.
> > > > > > >
> > > > > > > #3 is a no-brainer, just G-code.
> > > > > > >
> > > > > > > #1 and #3, it appears to me that by far the cleanest way to do
> > this this is by modifying the G-code interpreter to change the G43/G49
> > behavior - more specifically, by modifying the function
> > "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I
> > can see some other, rather mickey-mouse ways to do it, but this seems the
> > cleanest and most robust.
> > > > > > >
> > > > > > > Do I have this right?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Brad,

The hole is what I mentioned earlier - I have just over 4-1/2" of quill travel. I need 1", sometime 1.5" for rapid clearance, to clear clamps, fixtures, etc. Now I want to drill a 3" deep hole. I need a full 4-1/2" of quill travel for that one tool, so an optimal fixture offset is required to pull this off. That suggests a unique fixture for that one tool.

Another example - I have two endmills, and for both of them I choose a 2" fixture offset. But, since the offset is chosen rather arbitrarily, how do I account for the fact that with that 2" offset, the first endmill is 1.5" above the top of the workpiece (or whatever datum you choose), but the other one is 1.75" above the top of the workpiece? The G-code would have to KNOW the actual tool length, so it could correctly "fudge" the commanded Z positions when each tool is in use, as for the first tool Z=-1.5 would just touch the work, while for the second tool Z=-1.75 would just touch the work. Or, you'd have to still use tool offsets in addition to fixture offsets, but the tools offsets you put in the tool table would have to have the pre-selected fixture offsets subtracted from them.

Now, in the above example, suppose I break the shorter of those two endmills mid-program, and have to replace it, the pick up where I left off. But, where the original one was 1.5" above the workpiece, this one is now only 1.4" above the workpiece, because it's 0.1" longer. But, this 0.1" means you can no longer reach your clearance height? How do we correct for that on-the-fly? Or, the new tool is shorted, and you can no longer reach your maximum cut depth. We can't change the fixture offset, because that will screw up any other tools that share that same fixture.

I just don't see how it would work without jumping through a lot of hoops, a lot more manual effort, and introducing several new ways to shoot yourself in the foot (something I try very hard to avoid).

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
>
> Again this is just an exercise, so lets pick it apart.
>
> No, not on fixture per tool.
>
> The basic concept of what I am suggesting is to assign ranges of tools to different offsets based on their length.
>
> So tools 0-4" in length are zeroed to G54, 4-8" are G55 and 8-12" are G56.
>
> (Assuming you create 4" increments between the offsets)
>
> If you are using table==z0.0 then there is nothing left to do, otherwise use temporary part offset for material thickness if you prefer z0.0 at the top of the part.
>
> Make sense? Poke any holes if I am overlooking something, even if this approach is not ideal I would like to see if it is viable.
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > I'm afraid I'm not following you. Suppose I do what you suggest, and halfway through a job, I break a tool. So I replace it, but the length has now changed. How do I recover, unless I have one fixture per tool, and re-set the zero for that one fixture? Is that what you're suggesting?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > Ray,
> > >
> > >
> > >
> > > Bear with me as I get a little exhaustive in my problem solving thought
> > > trains.
> > >
> > >
> > >
> > > I do not believe there would be any maintenance of the offsets, once you
> > > had your original offset dialed in, the others would be offset a specific
> > > distance from each other based on the safe travel of your quill.
> > >
> > > Of course this only works if you are like me and do not like adjusting your
> > > offset every time you make a part and make your table z0.0 and program your
> > > part accordingly.
> > >
> > >
> > >
> > > Either way, it was just a temporary suggestion, when MM is released you will
> > > be able to handle this with ease via User callbacks + scripts with access to
> > > all required objects, including tool table.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > > Behalf Of himykabibble
> > > Sent: Sunday, November 06, 2011 11:01 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > I considered that approach a long time ago, but ruled it out pretty quickly.
> > > I think managing a slew of offsets like that would be a real PITA, and would
> > > REALLY complicate G-code generation, having to figure out which fixture to
> > > use when. I don't have any single jobs that need more than about 4-1/2" of
> > > travel, but I do have several that use pretty much all the quill travel
> > > between clearance height and drilling deep holes. I think you'd pretty much
> > > have to apply a different offset per tool, but I don't know the tool lengths
> > > when I generate the G-code. And, break a tool, and you've broken your code
> > > too.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Hello Ray,
> > > >
> > > > Well yours must be bigger than mine was... My quill was in the
> > > neighborhood of 6" and although my knee's ways were around 20" the
> > > knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
> > > >
> > > > Still, what do you think about just indexing the knee to different "work
> > > offsets"? This would not involve any 'axis swapping', just command a single
> > > axis move from the user callback and update whatever work offset you are
> > > currently using(G54/55/56/etc...)
> > > >
> > > > With this approach you would only ever be interpreting g code using the
> > > quill. You could probably implement this behavior right now as -is by using
> > > custom M codes to handle positioning the knee to preset levels in
> > > conjunction with setting up 3-4 work offsets to match these presets.
> > > >
> > > > As an example:
> > > >
> > > > G54 = X0.0 Y0.0 Z0.0
> > > > G55 = X0.0 Y0.0 Z-4.0
> > > > G56 = X0.0 Y0.0 Z-8.0
> > > > G57 = X0.0 Y0.0 Z-12.0
> > > >
> > > > Or something to that effect-I'm certain you get the idea.
> > > >
> > > >
> > > > Looking forward to working with other devs on the c#. There is already a
> > > rich framework for GUI in Machine Manager that allows for complete
> > > customization without adding a bunch of GUI to machine code plumbing.
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > "himykabibble" <jagboy@> wrote:
> > > > >
> > > > > Brad,
> > > > >
> > > > > "I also cannot think of a need to use the knee's marginally longer
> > > travel except the rare(rare being relative to the types of parts you might
> > > machine on a knee mill) occasion where you are contouring a very large
> > > part." - Not sure I understand that statement. My quill has a bit under 5"
> > > of travel, the knee has almost 20". The quill travel is adequate for any one
> > > tool, but on a given job, I will use tools that vary in length from 1"
> > > (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> > > > >
> > > > > I absolutely intend to look at what you're doing with C#, as that is my
> > > language of choice (at present.... :-)). In fact, I'm hoping to do my own UI
> > > for KMotionCNC in C# at some point. I'm glad to hear you will give scripting
> > > access to the internals. If that really would provide a way to do what I
> > > need without modifying Toms source code, that would be a nice way to go.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > , "bradodarb" <bradodarb@> wrote:
> > > > > >
> > > > > > Very interesting topic indeed.
> > > > > >
> > > > > > This is just a brain-dump, so take it with a grain....
> > > > > >
> > > > > >
> > > > > > I once had an old Kondia knee mill I planned to retrofit to CNC. My
> > > plan was to use the quill for the primary Z and index the knee as needed to
> > > shift around the Z's envelope of motion. If this is all you need then
> > > perhaps you could use the Interpreter's User Callback to call for an index
> > > and simply update your current fixture offset(G54/55/56/etc...).
> > > > > >
> > > > > > In this manner you can leave your tool comps accurate.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Other than that I cannot see a need to interpolate both z's. I also
> > > cannot think of a need to use the knee's marginally longer travel except the
> > > rare(rare being relative to the types of parts you might machine on a knee
> > > mill) occasion where you are contouring a very large part.
> > > > > >
> > > > > > Just because I cannot see a practical need does not mean that one does
> > > not exist, so please share a reason if you have one.
> > > > > >
> > > > > >
> > > > > > As Tom stated, I would be using IronPython scripts in my Usercallback
> > > handler(because I am using the c# gcode interface in Machine Manager).
> > > > > >
> > > > > > In a script you have complete and dynamic access to all Dynomotion and
> > > application objects. This makes custom integrations like what you are after
> > > a breeze(without the need for modifying source, etc...).
> > > > > >
> > > > > > Good luck with solving your challenge.
> > > > > >
> > > > > > My 2c,
> > > > > >
> > > > > > Brad Murry
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com
> > > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > > Â
> > > > > > > I think there are many ways to accomplish what you need. You
> > > should go ahead and do it whichever way you feel most comfortable with. It
> > > can't hurt anything to try. But here are some thoughts anyway :}
> > > > > > > Â
> > > > > > > Regarding swap axis: yes that was exactly what I was thinking. I
> > > don't really buy the "atomic" argument as most everything in GCode is modal
> > > anyway: incremental mode vs absolute for example. And also if the axes
> > > were incorrectly swapped, then the error would be something like moving the
> > > part up instead the tool down which would achieve almost the same thing
> > > anyway (I could think of worse things).
> > > > > > > Â
> > > > > > > Regarding that one line of code change: I don't think that will do
> > > it. I think I see about 2 dozen other areas you will need to modify. If
> > > I understand your approach it is to make a change such that the selected Z
> > > tool length offset will be applied to the A axis instead of the Z axis. Â
> > > Changing the current_a instead of current_z would confuse the Interpreter
> > > and not introduce the offset to the A axis as you desire. The "current"
> > > positions are basically where the Interpreter thinks it is at in
> > > Interpreter Space. The current position should differ from the absolute
> > > machine coordinates by any offsets. So ignoring all other offsets for a
> > > moment the relationship should be:
> > > > > > > Â
> > > > > > > MachineZ =Â CurrentZ + tool_length_offset
> > > > > > > Â
> > > > > > > So for example lets say the Interpreter DRO says the "current"
> > > position is 10 inches and we have a 1 inch tool_length_offset applied so
> > > the Machine Coordinates (ie distance from home switch) should be 11
> > > inches.Â
> > > > > > > Â
> > > > > > > 11Â =Â 10 + 1
> > > > > > > Â
> > > > > > > Now lets say we want to change the tool offset from 1 to 2 inches.Â
> > > Because the Machine didn't move the Machine coordinates remain the same so
> > > we must change the Interpreters current position to 9 to remain consistent:
> > > > > > > Â
> > > > > > > 11Â =Â 9 + 2
> > > > > > > Â Â
> > > > > > > If you do a global search in the code for tool_length_offset you
> > > will find about 2 dozen places where this offset is used in regard to z
> > > calculations. I think you will need to modify those places to affect the A
> > > axis instead.
> > > > > > > Â
> > > > > > > Regarding putting A,X,Y in the tool table besides the existing
> > > Length (Z): again you are right it would require the exact same changes, or
> > > rather additions to the Interpreter. Those 2 dozen locations would then
> > > need to modify X, Y, and A similar to what it does now with Z. But the
> > > advantage would be the User would then have a choice what it was to offset
> > > by changing the tool table without having to modify/re-compile the code to
> > > affect another axis.
> > > > > > > Â
> > > > > > > Regarding Macros: Yes we really need a way to run code on the PC to
> > > customize things to do the type of functionality Mach3 VB does. But it
> > > isn't clear to me what would be the best process. Brad seems to think
> > > Python would be the way to go.
> > > > > > > Â
> > > > > > > This is more of a question: Is the tool offset alone really
> > > sufficient to know where is the best place to position the knee?  Doesn't
> > > the thickness of the stock also factor in? For example the stock is a 1 ft
> > > cube and the tool is short and all you wish to do is mill the top surface
> > > flat. Wouldn't you want to put the knee way down in that case?
> > > > > > > Â
> > > > > > > You bring up lots of good points to stimulate discussion Ray.
> > > > > > > Â
> > > > > > > Thanks
> > > > > > > TK
> > > > > > >
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > >
> > > > > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > > > > >
> > > > > > >
> > > > > > > Â
> > > > > > > Tom,
> > > > > > >
> > > > > > > I don't see another obvious way to do this that would not require
> > > modification to the interpreter, or leave the door open for misbehavior, by
> > > making tool comp a non-atomic operation. The application, as I understand
> > > it, MUST be involved in the process, as only it has access to the tool
> > > table. So, if I don't modify the interpreter, it seems to me I'd have to
> > > insert something into the G-code BEFORE the G43/G49 to tell it I'm about to
> > > change the Z offset (this would presumably do the axis swap), then insert
> > > something AFTER the G43/G49 to tell it to un-swap the axes. What I don't
> > > like about this is, interrupting the program in the middle of this sequence
> > > will leave the machine in a state where the next Z or A axis move will move
> > > the wrong axis - not good!
> > > > > > >
> > > > > > > Looking at the code, it seems remarkably straight-forward -
> > > settings->current_z is directly modified by the magnitude of the tool length
> > > comp. It appears to me doing nothing more than changing that to
> > > settings->current_a would do the trick. This also appears to be the ONLY
> > > code that knows or cares a G43 or G49 is being processed. when I get my
> > > hands on VS, I'll have to give it a try. I sure can't see why it would not
> > > work.
> > > > > > >
> > > > > > > I don't see how adding an A offset to the tool table would help - it
> > > would require the exact same change in the interpreter to make it work
> > > properly.
> > > > > > >
> > > > > > > I am surprised there appears to be no common way of doing what I'm
> > > trying to do. It's not like there aren't a whole lot of knee mills out
> > > there! Mach3 also does not support it (yet - I put it on Brians ToDo list!),
> > > which is why I've had to create my own M-macros to do tool comp instead of
> > > using G43/G49. The macros work just fine, and the only down-side is my code
> > > is not portable to other machines, but I don't really much care about that.
> > > This was trivial to handle in Mach3, since I have direct access to the tool
> > > table within the macros. I could do the same thing in KMotionCNC if I had
> > > the ability to access the tool table and pass arguments to M-macros, but it
> > > appears to me I have neither.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com
> > > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > > ÂÂ
> > > > > > > > I suppose this would work. But it would be better to find a
> > > way to do it so you don't need to custom modify the Interpreter for your
> > > machines. I haven't looked at that code but if you aren't careful it
> > > might upset the relationship between Machine Coordinates and Interpreter
> > > Coordinates. Basically the DRO values on the Screen (and GCode numbers)
> > > map to actual machine coordinates through a whole bunch of offsets including
> > > tool length offsets. Then there are times when we need to re-sync the
> > > Interpreter back from Machine coordinates (after an MPG Jog for example).ÂÂ
> > > So you must be sure to keep both transformation directions consistent.
> > > > > > > > ÂÂ
> > > > > > > > It seems like what you are trying to do would be a common
> > > thing. Do you know how it is commonly accomplished?
> > > > > > > > ÂÂ
> > > > > > > > I was thinking that the fundamental issue is that there are two
> > > methods of moving the cutting tool toward the stock: move A up or Z down.ÂÂ
> > > So to me an MCode switch to specify which will move might make sense and we
> > > already have that functionality.
> > > > > > > > ÂÂ
> > > > > > > > Another thought would be to add an A offset to the tool table.ÂÂ
> > > We've considered adding x,y offsets in the past as I think that would work
> > > well with routers that have multiple spindles. Switching spindles could
> > > then be accomplished with a tool change which it what it really is.ÂÂ
> > > Right now I think it is common to use work offsets to handle it.
> > > > > > > > ÂÂ
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > > ÂÂ
> > > > > > > > ÂÂ
> > > > > > > > ÂÂ
> > > > > > > > ÂÂ
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: DynoMotion@yahoogroups.com
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > > > > >
> > > > > > > >
> > > > > > > > ÂÂ
> > > > > > > > Moving on.... I intend to use KMotionCNC, but I need to do some
> > > customizations, starting with tool changes and tool length compensation.
> > > Since I don't (yet) have a tool-changer, I need the program to pause so I
> > > can manually change the tool. I can't use G43/G49 to enable/disable length
> > > comp, since they will act on the Z axis, and I need tool length offsets
> > > applied to the A axis.
> > > > > > > >
> > > > > > > > A toolchange therefore requires several steps:
> > > > > > > >
> > > > > > > > 1) If tool length compensation is enabled, move the A axis (knee)
> > > to position 0.000 - think of this as a modified G49
> > > > > > > > 2) Prompt the user to load the new tool
> > > > > > > > 3) Execute an M6 Tn for the new tool
> > > > > > > > 3) If tool length compensation is subsequently enabled, move the A
> > > axis (knee) to the position given by the length parameter for the current
> > > tool. Think of this as a modified G43.
> > > > > > > >
> > > > > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n)
> > > into the G-code.
> > > > > > > >
> > > > > > > > #3 is a no-brainer, just G-code.
> > > > > > > >
> > > > > > > > #1 and #3, it appears to me that by far the cleanest way to do
> > > this this is by modifying the G-code interpreter to change the G43/G49
> > > behavior - more specifically, by modifying the function
> > > "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I
> > > can see some other, rather mickey-mouse ways to do it, but this seems the
> > > cleanest and most robust.
> > > > > > > >
> > > > > > > > Do I have this right?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

VS 2008 (Standard) is on order - only $61.80, including shipping!

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> The hole is what I mentioned earlier - I have just over 4-1/2" of quill travel. I need 1", sometime 1.5" for rapid clearance, to clear clamps, fixtures, etc. Now I want to drill a 3" deep hole. I need a full 4-1/2" of quill travel for that one tool, so an optimal fixture offset is required to pull this off. That suggests a unique fixture for that one tool.
>
> Another example - I have two endmills, and for both of them I choose a 2" fixture offset. But, since the offset is chosen rather arbitrarily, how do I account for the fact that with that 2" offset, the first endmill is 1.5" above the top of the workpiece (or whatever datum you choose), but the other one is 1.75" above the top of the workpiece? The G-code would have to KNOW the actual tool length, so it could correctly "fudge" the commanded Z positions when each tool is in use, as for the first tool Z=-1.5 would just touch the work, while for the second tool Z=-1.75 would just touch the work. Or, you'd have to still use tool offsets in addition to fixture offsets, but the tools offsets you put in the tool table would have to have the pre-selected fixture offsets subtracted from them.
>
> Now, in the above example, suppose I break the shorter of those two endmills mid-program, and have to replace it, the pick up where I left off. But, where the original one was 1.5" above the workpiece, this one is now only 1.4" above the workpiece, because it's 0.1" longer. But, this 0.1" means you can no longer reach your clearance height? How do we correct for that on-the-fly? Or, the new tool is shorted, and you can no longer reach your maximum cut depth. We can't change the fixture offset, because that will screw up any other tools that share that same fixture.
>
> I just don't see how it would work without jumping through a lot of hoops, a lot more manual effort, and introducing several new ways to shoot yourself in the foot (something I try very hard to avoid).
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> >
> > Again this is just an exercise, so lets pick it apart.
> >
> > No, not on fixture per tool.
> >
> > The basic concept of what I am suggesting is to assign ranges of tools to different offsets based on their length.
> >
> > So tools 0-4" in length are zeroed to G54, 4-8" are G55 and 8-12" are G56.
> >
> > (Assuming you create 4" increments between the offsets)
> >
> > If you are using table==z0.0 then there is nothing left to do, otherwise use temporary part offset for material thickness if you prefer z0.0 at the top of the part.
> >
> > Make sense? Poke any holes if I am overlooking something, even if this approach is not ideal I would like to see if it is viable.
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > I'm afraid I'm not following you. Suppose I do what you suggest, and halfway through a job, I break a tool. So I replace it, but the length has now changed. How do I recover, unless I have one fixture per tool, and re-set the zero for that one fixture? Is that what you're suggesting?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > > >
> > > > Ray,
> > > >
> > > >
> > > >
> > > > Bear with me as I get a little exhaustive in my problem solving thought
> > > > trains.
> > > >
> > > >
> > > >
> > > > I do not believe there would be any maintenance of the offsets, once you
> > > > had your original offset dialed in, the others would be offset a specific
> > > > distance from each other based on the safe travel of your quill.
> > > >
> > > > Of course this only works if you are like me and do not like adjusting your
> > > > offset every time you make a part and make your table z0.0 and program your
> > > > part accordingly.
> > > >
> > > >
> > > >
> > > > Either way, it was just a temporary suggestion, when MM is released you will
> > > > be able to handle this with ease via User callbacks + scripts with access to
> > > > all required objects, including tool table.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > > > Behalf Of himykabibble
> > > > Sent: Sunday, November 06, 2011 11:01 PM
> > > > To: DynoMotion@yahoogroups.com
> > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > I considered that approach a long time ago, but ruled it out pretty quickly.
> > > > I think managing a slew of offsets like that would be a real PITA, and would
> > > > REALLY complicate G-code generation, having to figure out which fixture to
> > > > use when. I don't have any single jobs that need more than about 4-1/2" of
> > > > travel, but I do have several that use pretty much all the quill travel
> > > > between clearance height and drilling deep holes. I think you'd pretty much
> > > > have to apply a different offset per tool, but I don't know the tool lengths
> > > > when I generate the G-code. And, break a tool, and you've broken your code
> > > > too.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > > "bradodarb" <bradodarb@> wrote:
> > > > >
> > > > > Hello Ray,
> > > > >
> > > > > Well yours must be bigger than mine was... My quill was in the
> > > > neighborhood of 6" and although my knee's ways were around 20" the
> > > > knee/saddle casting was huge resulting in maybe 7-8" of useful travel.
> > > > >
> > > > > Still, what do you think about just indexing the knee to different "work
> > > > offsets"? This would not involve any 'axis swapping', just command a single
> > > > axis move from the user callback and update whatever work offset you are
> > > > currently using(G54/55/56/etc...)
> > > > >
> > > > > With this approach you would only ever be interpreting g code using the
> > > > quill. You could probably implement this behavior right now as -is by using
> > > > custom M codes to handle positioning the knee to preset levels in
> > > > conjunction with setting up 3-4 work offsets to match these presets.
> > > > >
> > > > > As an example:
> > > > >
> > > > > G54 = X0.0 Y0.0 Z0.0
> > > > > G55 = X0.0 Y0.0 Z-4.0
> > > > > G56 = X0.0 Y0.0 Z-8.0
> > > > > G57 = X0.0 Y0.0 Z-12.0
> > > > >
> > > > > Or something to that effect-I'm certain you get the idea.
> > > > >
> > > > >
> > > > > Looking forward to working with other devs on the c#. There is already a
> > > > rich framework for GUI in Machine Manager that allows for complete
> > > > customization without adding a bunch of GUI to machine code plumbing.
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > > "himykabibble" <jagboy@> wrote:
> > > > > >
> > > > > > Brad,
> > > > > >
> > > > > > "I also cannot think of a need to use the knee's marginally longer
> > > > travel except the rare(rare being relative to the types of parts you might
> > > > machine on a knee mill) occasion where you are contouring a very large
> > > > part." - Not sure I understand that statement. My quill has a bit under 5"
> > > > of travel, the knee has almost 20". The quill travel is adequate for any one
> > > > tool, but on a given job, I will use tools that vary in length from 1"
> > > > (small endmills), to almost 8" (long drill bits), so I MUST use the knee.
> > > > > >
> > > > > > I absolutely intend to look at what you're doing with C#, as that is my
> > > > language of choice (at present.... :-)). In fact, I'm hoping to do my own UI
> > > > for KMotionCNC in C# at some point. I'm glad to hear you will give scripting
> > > > access to the internals. If that really would provide a way to do what I
> > > > need without modifying Toms source code, that would be a nice way to go.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > , "bradodarb" <bradodarb@> wrote:
> > > > > > >
> > > > > > > Very interesting topic indeed.
> > > > > > >
> > > > > > > This is just a brain-dump, so take it with a grain....
> > > > > > >
> > > > > > >
> > > > > > > I once had an old Kondia knee mill I planned to retrofit to CNC. My
> > > > plan was to use the quill for the primary Z and index the knee as needed to
> > > > shift around the Z's envelope of motion. If this is all you need then
> > > > perhaps you could use the Interpreter's User Callback to call for an index
> > > > and simply update your current fixture offset(G54/55/56/etc...).
> > > > > > >
> > > > > > > In this manner you can leave your tool comps accurate.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Other than that I cannot see a need to interpolate both z's. I also
> > > > cannot think of a need to use the knee's marginally longer travel except the
> > > > rare(rare being relative to the types of parts you might machine on a knee
> > > > mill) occasion where you are contouring a very large part.
> > > > > > >
> > > > > > > Just because I cannot see a practical need does not mean that one does
> > > > not exist, so please share a reason if you have one.
> > > > > > >
> > > > > > >
> > > > > > > As Tom stated, I would be using IronPython scripts in my Usercallback
> > > > handler(because I am using the c# gcode interface in Machine Manager).
> > > > > > >
> > > > > > > In a script you have complete and dynamic access to all Dynomotion and
> > > > application objects. This makes custom integrations like what you are after
> > > > a breeze(without the need for modifying source, etc...).
> > > > > > >
> > > > > > > Good luck with solving your challenge.
> > > > > > >
> > > > > > > My 2c,
> > > > > > >
> > > > > > > Brad Murry
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com
> > > > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > > Â
> > > > > > > > I think there are many ways to accomplish what you need. You
> > > > should go ahead and do it whichever way you feel most comfortable with. It
> > > > can't hurt anything to try. But here are some thoughts anyway :}
> > > > > > > > Â
> > > > > > > > Regarding swap axis: yes that was exactly what I was thinking. I
> > > > don't really buy the "atomic" argument as most everything in GCode is modal
> > > > anyway: incremental mode vs absolute for example. And also if the axes
> > > > were incorrectly swapped, then the error would be something like moving the
> > > > part up instead the tool down which would achieve almost the same thing
> > > > anyway (I could think of worse things).
> > > > > > > > Â
> > > > > > > > Regarding that one line of code change: I don't think that will do
> > > > it. I think I see about 2 dozen other areas you will need to modify. If
> > > > I understand your approach it is to make a change such that the selected Z
> > > > tool length offset will be applied to the A axis instead of the Z axis. Â
> > > > Changing the current_a instead of current_z would confuse the Interpreter
> > > > and not introduce the offset to the A axis as you desire. The "current"
> > > > positions are basically where the Interpreter thinks it is at in
> > > > Interpreter Space. The current position should differ from the absolute
> > > > machine coordinates by any offsets. So ignoring all other offsets for a
> > > > moment the relationship should be:
> > > > > > > > Â
> > > > > > > > MachineZ =Â CurrentZ + tool_length_offset
> > > > > > > > Â
> > > > > > > > So for example lets say the Interpreter DRO says the "current"
> > > > position is 10 inches and we have a 1 inch tool_length_offset applied so
> > > > the Machine Coordinates (ie distance from home switch) should be 11
> > > > inches.Â
> > > > > > > > Â
> > > > > > > > 11Â =Â 10 + 1
> > > > > > > > Â
> > > > > > > > Now lets say we want to change the tool offset from 1 to 2 inches.Â
> > > > Because the Machine didn't move the Machine coordinates remain the same so
> > > > we must change the Interpreters current position to 9 to remain consistent:
> > > > > > > > Â
> > > > > > > > 11Â =Â 9 + 2
> > > > > > > > Â Â
> > > > > > > > If you do a global search in the code for tool_length_offset you
> > > > will find about 2 dozen places where this offset is used in regard to z
> > > > calculations. I think you will need to modify those places to affect the A
> > > > axis instead.
> > > > > > > > Â
> > > > > > > > Regarding putting A,X,Y in the tool table besides the existing
> > > > Length (Z): again you are right it would require the exact same changes, or
> > > > rather additions to the Interpreter. Those 2 dozen locations would then
> > > > need to modify X, Y, and A similar to what it does now with Z. But the
> > > > advantage would be the User would then have a choice what it was to offset
> > > > by changing the tool table without having to modify/re-compile the code to
> > > > affect another axis.
> > > > > > > > Â
> > > > > > > > Regarding Macros: Yes we really need a way to run code on the PC to
> > > > customize things to do the type of functionality Mach3 VB does. But it
> > > > isn't clear to me what would be the best process. Brad seems to think
> > > > Python would be the way to go.
> > > > > > > > Â
> > > > > > > > This is more of a question: Is the tool offset alone really
> > > > sufficient to know where is the best place to position the knee?  Doesn't
> > > > the thickness of the stock also factor in? For example the stock is a 1 ft
> > > > cube and the tool is short and all you wish to do is mill the top surface
> > > > flat. Wouldn't you want to put the knee way down in that case?
> > > > > > > > Â
> > > > > > > > You bring up lots of good points to stimulate discussion Ray.
> > > > > > > > Â
> > > > > > > > Thanks
> > > > > > > > TK
> > > > > > > >
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > >
> > > > > > > > Sent: Sunday, November 6, 2011 4:17 PM
> > > > > > > > Subject: [DynoMotion] Re: Customizing Tool Changes
> > > > > > > >
> > > > > > > >
> > > > > > > > Â
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > I don't see another obvious way to do this that would not require
> > > > modification to the interpreter, or leave the door open for misbehavior, by
> > > > making tool comp a non-atomic operation. The application, as I understand
> > > > it, MUST be involved in the process, as only it has access to the tool
> > > > table. So, if I don't modify the interpreter, it seems to me I'd have to
> > > > insert something into the G-code BEFORE the G43/G49 to tell it I'm about to
> > > > change the Z offset (this would presumably do the axis swap), then insert
> > > > something AFTER the G43/G49 to tell it to un-swap the axes. What I don't
> > > > like about this is, interrupting the program in the middle of this sequence
> > > > will leave the machine in a state where the next Z or A axis move will move
> > > > the wrong axis - not good!
> > > > > > > >
> > > > > > > > Looking at the code, it seems remarkably straight-forward -
> > > > settings->current_z is directly modified by the magnitude of the tool length
> > > > comp. It appears to me doing nothing more than changing that to
> > > > settings->current_a would do the trick. This also appears to be the ONLY
> > > > code that knows or cares a G43 or G49 is being processed. when I get my
> > > > hands on VS, I'll have to give it a try. I sure can't see why it would not
> > > > work.
> > > > > > > >
> > > > > > > > I don't see how adding an A offset to the tool table would help - it
> > > > would require the exact same change in the interpreter to make it work
> > > > properly.
> > > > > > > >
> > > > > > > > I am surprised there appears to be no common way of doing what I'm
> > > > trying to do. It's not like there aren't a whole lot of knee mills out
> > > > there! Mach3 also does not support it (yet - I put it on Brians ToDo list!),
> > > > which is why I've had to create my own M-macros to do tool comp instead of
> > > > using G43/G49. The macros work just fine, and the only down-side is my code
> > > > is not portable to other machines, but I don't really much care about that.
> > > > This was trivial to handle in Mach3, since I have direct access to the tool
> > > > table within the macros. I could do the same thing in KMotionCNC if I had
> > > > the ability to access the tool table and pass arguments to M-macros, but it
> > > > appears to me I have neither.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > > > --- In DynoMotion@yahoogroups.com
> > > > <mailto:DynoMotion%40yahoogroups.com> , Tom Kerekes <tk@> wrote:
> > > > > > > > >
> > > > > > > > > Hi Ray,
> > > > > > > > > ÂÂ
> > > > > > > > > I suppose this would work. But it would be better to find a
> > > > way to do it so you don't need to custom modify the Interpreter for your
> > > > machines. I haven't looked at that code but if you aren't careful it
> > > > might upset the relationship between Machine Coordinates and Interpreter
> > > > Coordinates. Basically the DRO values on the Screen (and GCode numbers)
> > > > map to actual machine coordinates through a whole bunch of offsets including
> > > > tool length offsets. Then there are times when we need to re-sync the
> > > > Interpreter back from Machine coordinates (after an MPG Jog for example).ÂÂ
> > > > So you must be sure to keep both transformation directions consistent.
> > > > > > > > > ÂÂ
> > > > > > > > > It seems like what you are trying to do would be a common
> > > > thing. Do you know how it is commonly accomplished?
> > > > > > > > > ÂÂ
> > > > > > > > > I was thinking that the fundamental issue is that there are two
> > > > methods of moving the cutting tool toward the stock: move A up or Z down.ÂÂ
> > > > So to me an MCode switch to specify which will move might make sense and we
> > > > already have that functionality.
> > > > > > > > > ÂÂ
> > > > > > > > > Another thought would be to add an A offset to the tool table.ÂÂ
> > > > We've considered adding x,y offsets in the past as I think that would work
> > > > well with routers that have multiple spindles. Switching spindles could
> > > > then be accomplished with a tool change which it what it really is.ÂÂ
> > > > Right now I think it is common to use work offsets to handle it.
> > > > > > > > > ÂÂ
> > > > > > > > > Regards
> > > > > > > > > TK
> > > > > > > > > ÂÂ
> > > > > > > > > ÂÂ
> > > > > > > > > ÂÂ
> > > > > > > > > ÂÂ
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ________________________________
> > > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > > To: DynoMotion@yahoogroups.com
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > > Sent: Saturday, November 5, 2011 8:38 PM
> > > > > > > > > Subject: [DynoMotion] Customizing Tool Changes
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ÂÂ
> > > > > > > > > Moving on.... I intend to use KMotionCNC, but I need to do some
> > > > customizations, starting with tool changes and tool length compensation.
> > > > Since I don't (yet) have a tool-changer, I need the program to pause so I
> > > > can manually change the tool. I can't use G43/G49 to enable/disable length
> > > > comp, since they will act on the Z axis, and I need tool length offsets
> > > > applied to the A axis.
> > > > > > > > >
> > > > > > > > > A toolchange therefore requires several steps:
> > > > > > > > >
> > > > > > > > > 1) If tool length compensation is enabled, move the A axis (knee)
> > > > to position 0.000 - think of this as a modified G49
> > > > > > > > > 2) Prompt the user to load the new tool
> > > > > > > > > 3) Execute an M6 Tn for the new tool
> > > > > > > > > 3) If tool length compensation is subsequently enabled, move the A
> > > > axis (knee) to the position given by the length parameter for the current
> > > > tool. Think of this as a modified G43.
> > > > > > > > >
> > > > > > > > > #2 is, I think trivial - I can just insert a (MSG,Load tool #n)
> > > > into the G-code.
> > > > > > > > >
> > > > > > > > > #3 is a no-brainer, just G-code.
> > > > > > > > >
> > > > > > > > > #1 and #3, it appears to me that by far the cleanest way to do
> > > > this this is by modifying the G-code interpreter to change the G43/G49
> > > > behavior - more specifically, by modifying the function
> > > > "convert_tool_length_offset" to act on the A axis, rather than the Z axis. I
> > > > can see some other, rather mickey-mouse ways to do it, but this seems the
> > > > cleanest and most robust.
> > > > > > > > >
> > > > > > > > > Do I have this right?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Ray L.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>